Hallo zusammen. Ich habe mich jetzt einige Zeit mit PIC12 bis hin zu PIC24 beschäftigt (also 8bit und 16bit), verstehe im Allgemeinen auch wie da was funktioniert. Nun will ich einen Schritt weiter gehen. Statt den PIC32 würde ich gerne eher auf einen Hersteller mit Low-End bis High-End ARMs wechseln, damit ich, wenn ich die etwas einfacheren ARMs beherrsche, auch die größeren, schnelleren ARMs vom gleichen Hersteller nehmen kann. -Macht das überhaupt Sinn oder sind die dann trotzdem so sehr anders wie ARMs von einem anderen Hersteller? Da hab ich mir dann aber die Frage gestellt, ob ich nicht (vorerst) eine andere Baustelle angehe, nähmlich die FPGAs. Das ist mal was anderes, jedoch hab ich das Problem, dass ich mir kein Projekt vorstellen kann, das man besser mit einem FPGA realisiert als mit einem µC, speziell ARM. Anders rum eher, auf einen ARM kann man ein Linux packen, man kann auch auf einen schnellen ADC zugreifen (für das Beispiel eines kleinen Oszi's), Videoanzeige auf einem TFT, usw. Da fehlt mir irgendwie noch die Vorstellungskraft. Ich weiß, dass FPGAs kein Programm Befehl nach Befehl abarbeitet, sondern dass die Logikfunktionen "verdrahtet" werden, sodass Signale parallel und sofort verarbeitet werden. Einen FPGA dafür zu nutzen, dass ein paar Logik-Gatter ersetzt werden und auch in einem Gehäuse und somit besser zu verdrahten sind, dafür ist ein FPGA ein wenig overkill. -Was wären denn ein paar Ideen, was man damit basteln könnte? Lauflichter, Anzeigen usw.. zum Einstieg vielleicht. Ich wollte dann damit aber auch schon ein sinnvolles Projekt realisieren. -Warum sind FPGAs (im Vergleich zu µC) so teuer? Man bekommt ein Eval-Board mit einem Cortex-M4 für nen 5er hinterher geworfen, aber ein einzelner FPGA kostet locker 15-20€? Silizium ist doch Silizium und die neueren ARMs sind doch bestimmt auch schon im 2-stelligen nm-Herstellungsbereich!? Ich hab auch alternativ an CPLDs gedacht, die sind kleiner (besser handhabbar da angenehmere Gehäuse) und günstiger, ggf auch einfacher zu lernen. Doch so wie sich das im Artiekl auf dieser Seite anhört, sind die mit ein paar Gattern dann auch schon voll (30 FlipFlops klingt irgendwie sehr wenig) und sind damit doch auch deutlich schneller "voll" als ein FPGA. Ich weiß einfach nicht, in welche Richtung ich gehen soll. Eine neue IDE, Programmierer, Compiler und Tutorials/Lernstoff brauche ich sowieso. Ich habe ein STM32F4DISCOVERY sowie ein Board mit dem Xilinx XC3S250 inkl. LEDs, Taster und anderer Schnickschnack (Das Ding wird leider noch per Parallelport beschrieben). Ein eigener USB-Programmer wollte ich aber schon haben. -Ist aber bei ARM UND FPGA J-TAG oder? Vielen Dank für jegliche Empfehlungen, Ratschläge oder Antworten. MFG
ich schrieb: > Ich weiß einfach nicht, in welche Richtung ich gehen soll. Eine neue > IDE, Programmierer, Compiler und Tutorials/Lernstoff brauche ich > sowieso. Hallo Du /ich, Wenn Du vorwiegend HW entwicklen möchtest dann bist Du in der Ecke CPLD/FPGA gut aufgehoben. Dort kannst Du notfalls auch Prozessorkerne mit die die größeren FPGAs mit keinklemmmen und hast dan ein kleines PSOC, wird aber sicher kein uC a'la STM32F407 da reingehen. Wenn Du eher ganze Systeme bauen willst um damit auch SW zu machen, mit RTOS villeicht oder kleinem OS, dann gehe Richtung ARM. Erwarte Dir aber nicht zu viel nach dem Motto "und in wenigen Wochen prgrammiere ich dann mein' Tablet-PC mit ArmA8 um". Jemand der Beides kann und abwechselnd Beides macht. rgds
Ja, ich bin eher der Hardware statt Software Typ (Ohne Software gehts aber natürlich auch nicht). Also ein Tablet will ich nicht umbedingt machen, aber so ein kleines Oszi... Es muss nicht umbedingt Hochgenau sein, sondern eher die einzelnen Stufen begreifen und entwickeln. Wenn man das Oszi mal als Beispiel nimmt: Ich habe schon gesehen, das manche hier das mit einem FPGA oder CPLD gemacht haben, aber wo ist der Vorteil gegenüber einen ARM? Leistungstechnisch sollte für einen 200MSPS ADC doch auch ein 1GHz ARM "reichen", oder übersehe ich da was? Ist das mit einem FPGA einfacher? Als Beispiel die Anbindung eines Arbeitsspeichers sollte ein ARM doch auch hinbekommen, oder?
ich schrieb: > -Warum sind FPGAs (im Vergleich zu µC) so teuer? Man bekommt ein > Eval-Board mit einem Cortex-M4 für nen 5er hinterher geworfen, Ich würde das mal "Werbeaktion" nennen... > aber ein einzelner FPGA kostet locker 15-20€? Es geht aber schon bei 6$ los: http://www.digikey.de/product-detail/de/LAMXO256E-3TN100E/220-1638-ND/2731596 > aber ein einzelner FPGA kostet locker 15-20€? Und ein einzelner Cortex-M4 uC? > ein einzelner FPGA FPGA = Feldprogrammierbares Gatearray Und man sagt nicht der Array, sondern das Array. Also heißt es korrekt "ein einzelnes FPGA"... > Ein eigener USB-Programmer wollte ich aber schon haben. > -Ist aber bei ARM UND FPGA J-TAG oder? Ja. Hat aber trotzdem nichts miteinander zu tun, und der eine Programmer kann nicht so ohne weiteres den anderen Baustein beschreiben. Und sobald es dann in richtung "Debuggen" oder "On-Chip-Diagnose" geht, dann funktioniert "One-Size-Fits-All" (=ein Programmer für alle Bausteine) garantiert nicht mehr. > Ich hab auch alternativ an CPLDs gedacht ... > so wie sich das im Artiekl auf dieser Seite anhört, sind > die mit ein paar Gattern dann auch schon voll (30 FlipFlops klingt > irgendwie sehr wenig) Das ist auch tatsächlich ganz arg wenig... > und sind damit doch auch deutlich schneller "voll" als ein FPGA. Und zudem (du willst ja was Neues lernen) sind CPLDs sogar vom eigentlichen CPLD-Erfinder Lattice inzwischen für nicht überlebensfähig erklärt worden: Lattice verkauft seine "kleinen" FPGAs unter dem Deckmäntelchen CPLD, um potentielle Umsteiger nicht abzuschrecken...
Lothar Miller schrieb: > Ich würde das mal "Werbeaktion" nennen... Wieso machen das die FPGA-Hersteller nicht? ;) Die Boards, die ich gesehen habe, liegen so bei 80€+ Lothar Miller schrieb: >> ein einzelner FPGA > FPGA = Feldprogrammierbares Gatearray > Und man sagt nicht der Array, sondern das Array. > Also heißt es korrekt "ein einzelnes FPGA"... Verzeih, hast recht ;) Lothar Miller schrieb: >> aber ein einzelner FPGA kostet locker 15-20€? > Es geht aber schon bei 6$ los: > http://www.digikey.de/product-detail/de/LAMXO256E-3TN100E/220-1638-ND/2731596 >> aber ein einzelner FPGA kostet locker 15-20€? > Und ein einzelner Cortex-M4 uC? Naja, wenn man es so sieht. Bei Mouser kostet der billigste FPGA 1,36€ und der billigste ARM Cortex-M4 1,34€. Die Frage ist, wie man die vergleichen kann. Man muss ja zum vergleichen eine gleiche Leistungsklasse nehmen. Dann hab ich mich bei den 15€ wohl verguckt. War auch Reichelt, die haben kaum Auswahl, da ist auch der billigste der Spartan-3 XC3S200 für 12,50€. Allerdings sind sogut wie alle günstigen FPGAs in BGA oder QFN-Gehäuse, aber das ist ja eine andere Sache. Ich habe interessehalber auch mal geguckt, wo so die Obergrenze ist: ARM: CYUSB3014-BZXI für 34,69€ FPGA (Konfigurationsspeicher): EPC16UC88N für 71,78€ FPGA (Universalschaltkreis): EP4SGX530HH35C3N für 7.614,75 verfluchte Euro Ist der aus Platin und wurde vom Papst gesegnet? ;) Lothar Miller schrieb: > Ja. Hat aber trotzdem nichts miteinander zu tun, und der eine Programmer > kann nicht so ohne weiteres den anderen Baustein beschreiben. Und sobald > es dann in richtung "Debuggen" oder "On-Chip-Diagnose" geht, dann > funktioniert "One-Size-Fits-All" (=ein Programmer für alle Bausteine) > garantiert nicht mehr. Dachte ich mir irgendwie schon. Ich dachte schon, das J-TAG irgendwie so genormt ist, dass alle Bauteile mit J-TAG-Schnittstelle programmiert werden können. Lothar Miller schrieb: > Lattice verkauft seine "kleinen" FPGAs unter dem > Deckmäntelchen CPLD, um potentielle Umsteiger nicht abzuschrecken... Auch nicht schlecht;) Solange ich da kein Riesen-IC hinpacken muss, nehme ich auch lieber nen FPGA.
Hallo; "Microcontroller oder FPGA" Warum eigentlich oder: Es gibt development Kits welche FPGA und Microcontroller kombinieren Auch habe ich ankündigungen von FPGA Herstellern gehört, Microcontroller kerne und FPGA auf einer chipfläche zu integrieren. Beispiel: http://www.silica.com/product/silica-xynergy-board-stm32-meets-spartan-6.html Gruß
ich schrieb: > FPGA (Universalschaltkreis): EP4SGX530HH35C3N für 7.614,75 verfluchte > Euro > Ist der aus Platin und wurde vom Papst gesegnet? ;) Ach das war auch mit dem Filter "Lagernd". Ohne gibts noch den 5SGTMC7K2F40C2ES für 26.508,08 €... Das sind doch keine echten Preise, oder?
Marc Rupprath schrieb: > Es gibt development Kits welche FPGA und Microcontroller kombinieren > Auch habe ich ankündigungen von FPGA Herstellern gehört, Microcontroller > kerne und FPGA auf einer chipfläche zu integrieren. Das ist sowas ähnliches, oder?: Altera Cyclone V SE SoC FPGA with ARM-based HPS and logic Marc Rupprath schrieb: > Warum eigentlich oder: Weil ich erstmal eins von beiden auf die Rolle kriegen will. Wenn das eine dann läuft kann ich auch das andere nehmen. Wenn ich also ein FPGA und ARM in einem Chip habe, würde ich erstmal das eine und dann das andere (ggf Monate später) benutzen. Dann kann ich auch einzelne Teile nehmen.
ich schrieb: > Warum sind FPGAs (im Vergleich zu µC) so teuer? Der Mensch ist single-Tasker. Es fällt ihm also bedeutend leichter, ein Programm zu erstellen bzw. zu verstehen, was sequentiell abgearbeitet wird, wie eine CPU es tut. FPGA nimmt er nur, wenn das nicht mehr ausreicht und parallel gearbeitet werden muß. FPGA werden daher nur für Nischenanwendungen eingesetzt und sind deshalb teuer. Auch sind die Entwicklungstools deutlich komplexer.
ich schrieb: > Hallo zusammen. Ich habe mich jetzt einige Zeit mit PIC12 bis hin zu > PIC24 beschäftigt (also 8bit und 16bit), verstehe im Allgemeinen auch > wie da was funktioniert. > Nun will ich einen Schritt weiter gehen. Statt den PIC32 würde ich gerne > eher auf einen Hersteller mit Low-End bis High-End ARMs wechseln, damit > ich, wenn ich die etwas einfacheren ARMs beherrsche, auch die größeren, > schnelleren ARMs vom gleichen Hersteller nehmen kann. > -Macht das überhaupt Sinn oder sind die dann trotzdem so sehr anders wie > ARMs von einem anderen Hersteller? Ich sag mal so: Du wirst in C programmieren, und da bekommst Du nicht viel davon mit, was für ein Prozessorkern dadrunter ist. Ob MIPS, ARM oder AVR32, das ist auf Hochsprachenebene so ziemlich egal. Der Unterschied ist in der Peripherie, und da unterschieden sich zwei ARM-Derivate so viel wie PIC32 und AVR32. Heißt also: Wenn Du PIC32 kannst (für den Du ja schon alle Tools da hast), dann wird Dir der Umstieg auf irgendeinen anderen 32 Bitter nicht schwer fallen. Innerhalb der Linien eines Herstellers ist die Peripherie meist identisch, denn der will ja auch nicht unnötig neu entwickeln oder zukaufen. Ausnahme sind zugekaufte Produktfamilien wie zB einige Bausteine bei NXP, die original von Sharp kommen. > -Warum sind FPGAs (im Vergleich zu µC) so teuer? Man bekommt ein > Eval-Board mit einem Cortex-M4 für nen 5er hinterher geworfen, aber ein > einzelner FPGA kostet locker 15-20€? Silizium ist doch Silizium und die > neueren ARMs sind doch bestimmt auch schon im 2-stelligen > nm-Herstellungsbereich!? Stückzahlen. Außerdem sind die Evalboards oft subventioniert. fchk
Peter Dannegger schrieb: > Der Mensch ist single-Tasker. Es fällt ihm also bedeutend leichter, ein > Programm zu erstellen bzw. zu verstehen, was sequentiell abgearbeitet > wird, wie eine CPU es tut. > FPGA nimmt er nur, wenn das nicht mehr ausreicht und parallel gearbeitet > werden muß. > FPGA werden daher nur für Nischenanwendungen eingesetzt und sind deshalb > teuer. Auch sind die Entwicklungstools deutlich komplexer. Achso, das kann sein. Ich würde zuerst den FPGA auch mittels Schaltung "Programmieren". Es gibt in der IDE von Xilinx doch eine Möglichkeit, Gatter oder andere Teile (Flipflops, Counter etc) zu plazieren und zu verdrahten. Da kann ich mir das besser vorstellen ;) Frank K. schrieb: > Innerhalb der Linien eines Herstellers ist die Peripherie meist > identisch, denn der will ja auch nicht unnötig neu entwickeln oder > zukaufen. Das ergibt Sinn. Ich bin davon begeistert, wie Microchip durch die Familien hindurch ihre Bezeichnungen usw ziehen. Der Sprung vom PIC16 zum PIC24 ist einfacher gewesen als ich dachte und die Datenblätter sind auch gleich aufgebaut. Gleiche IDE und für alles das PICKIT3. Ich weiß halt nur nich, in wiefern das bei anderen Herstellern auch so ist. Wenn ich mich für ARM entscheiden sollte, muss ich sowieso nochmal gucken welche Firma es wird. Denke aber bei ARM ST oder NXP. Beim FPGS Xilinx oder Altera (man hat da ja auch weniger Auswahl;) ). Wie kommt es eigentlich, dass es bei FPGAs nicht so viele Hersteller gibt, wie bei Microcontrollern? Grade wegen den niedrigeren Stückzahlen? Ich mein, fast alle Firmen haben Mikrocontroller, sogar Analog Devices oder Maxim, die ja sonst eher andere Sachen machen. Microchip hatte mal versucht die AVRs aufzukaufen und hat auch ein paar 8085er im Programm. Aber keiner von den macht in FPGAs. Altera macht ansich nur FPGAs (+ ASICs und CPLDs) und Xilinx, Lattice und Actel/Microsemi auch.
Wenn du dich mit FPGA beschäftigen willst, kommst du um VHDL (oder verilog) mittelfristig nicht herum: eine Hardware-Beschreibungssprache, fühlt sich deutlich anders an als eine SW-Programmiersprache. Klar, man kann auch schematic die Gatter zusammenklicken, aber ein solches Design ist nicht portabel und im Hardware-Bereich FPGA bzw Asic absolut unüblich. Ich empfehle eine Einarbeitung in VHDL. Es gibt im Netz genügend Tutorials und Simulatoren. Wenns Spass macht, kannst du anschliessend eine im Netz befindliche Entwicklungsumgebung ausprobieren. Im Nachbarforum "FPGA, VHDL & co" findest du weitere Tipps.
Nachtrag: FPGAs und Asics kommen immer dann zum Zuge, wenn es richtig (!) schnell gehen muss und ein passender Standard-Chip oder eine passende Pheripherie in einem Controller nicht passt. Das mit dem selbstgebauten Oszi geht schon in die Richtung. Andere Beispiele sind Verarbeiten, Umpacken oder Auskoppeln schneller Datenströme aus dem Kommunikations- oder Videobereich.
ich schrieb: > Achso, das kann sein. Ich würde zuerst den FPGA auch mittels Schaltung > "Programmieren". Es gibt in der IDE von Xilinx doch eine Möglichkeit, > Gatter oder andere Teile (Flipflops, Counter etc) zu plazieren und zu > verdrahten. Da kann ich mir das besser vorstellen ;) Jaja, ich verweise da dann auf den langen und trotzdem lesenswerten Beitrag "kruder Fehler bei FPGA-Programmierung (ISE WEBpack-Schematic)"
Ich bin da mal drüber geflogen.. Ich verstehe nicht, wie manche über die Syntax von C meckern können, solange es VHDL gibt^^ Das sieht ja grausam aus, auch wenn du damit alle zum staunen bringst ;) Ich denke ich werde mir mal einen kleinen FPGA antun und mal sehen wie es wird.
ich schrieb: > Ich verstehe nicht, wie manche über die Syntax von C meckern können, > solange es VHDL gibt^^ > Das sieht ja grausam aus Dann sieh dir mal Verilog an... ;-) http://www.lothar-miller.de/s9y/archives/88-VHDL-vs.-Verilog-am-Beispiel-einer-Stoppuhr.html
ich schrieb: > Achso, das kann sein. Ich würde zuerst den FPGA auch mittels Schaltung > "Programmieren". Es gibt in der IDE von Xilinx doch eine Möglichkeit, > Gatter oder andere Teile (Flipflops, Counter etc) zu plazieren und zu > verdrahten. Da kann ich mir das besser vorstellen ;) So dachte ich auch mal .. das war zu Zeiten von ISE3 ;) Ich bin aber sehr schnell bei VHDL gelandet, weil das viel einfacher und effektiver ist. Die Einarbeitungszeit für den Schaltplaneditor sollte man in das Lernen von VHDL investieren.
ich schrieb: > Ich hab auch alternativ an CPLDs gedacht, Also erstmal eines: Was man sinnvoll mit einem µC machen kann, sollte man auch mit einem µC machen. Was lieber nicht mit einem µC, dafür aber man mit einem CPLD machen kann, sollte man auch mit einem CPLD machen. Der Rest ist FPGA. Der Nachteil von FPGA's ist oft (aber nicht immer) die Konfiguration. Ein programmiertes CPLD funktioniert ab Stromeinschalten, ein FPGA muß erstmal seinen Code hineingelöffelt bekommen. Das braucht Zeit und zumeist einen teuren Konfigurations-Speicher, der auch noch richtig angeschlossen sein will. Schlimme Beispiele sieht man in diesem Board: µC, die als LCD-Treiber mißbraucht werden, was zwar irgendwie hinzukriegen ist, aber dennoch keinen echten Nutzwert hat. Oder Controller als DDS-IC, die zwar grottenschlecht sind im Vergleich zu echten DDS-IC, aber dennoch erstaunlich beliebt. Das Gegenbeispiel sind diverse Softcores für FPGA's, wo man einen doch eher exotischen µC auf einem FPGA dabei herausbekommt, intellektuell ja ganz nett, aber jeder handelsübliche echte µC schlägt sowas, entweder in der Leistung oder ökonomisch oder beides. Also: Alles hat seinen Platz und als Geräteentwickler muß man auf beiden Hochzeiten tanzen. Ich frag mich aber bei dem TO, was er denn bislang an Kreationen vollbracht hat, also was für Geräte bei seinen PIC-Beschäftigungen "Ich habe mich jetzt einige Zeit mit PIC12 bis hin zu PIC24 beschäftigt" herausgekommen ist - und was er mit einer neuen Beschäftigung mit nem ARM oder nem FPGA erzielen will? W.S.
W.S. schrieb: > Was man sinnvoll mit einem µC machen kann, sollte man auch mit einem > µC machen. > Was lieber nicht mit einem µC, dafür aber man mit einem CPLD machen > kann, sollte man auch mit einem CPLD machen. Der Rest ist FPGA. Das ist ja ein wenig mein Problem, dass ich die Grenzen nicht genau sehe, also was besser für was ist. Ich hatte bisher nur was mit kleineren bis mittleren µCs zutun und hab mir dazu "passend" Projekte ausgedacht. Mit den Teilen ging auch erstaunlich viel, da oft eher das Mechanische oder Aussehen das Problem war und nicht die Software. Beim ARM schwebte mir etwas mit Linux vor.. Aber ein Board mit einem Linux.. und dann? Ähnlich beim FPGA: Irgendwas, wo man einen hohen Datenstrom schnell und parallel abarbeiten muss.. Aber welchen/was? Einen (gekauften) Logik-Analyser hab ich schon. W.S. schrieb: > Der Nachteil von FPGA's ist oft (aber nicht immer) die Konfiguration. > Ein programmiertes CPLD funktioniert ab Stromeinschalten, ein FPGA muß > erstmal seinen Code hineingelöffelt bekommen. Das braucht Zeit und > zumeist einen teuren Konfigurations-Speicher, der auch noch richtig > angeschlossen sein will. Gibt es nicht auch FPGAs, die einen Flash- oder RAM-Speicher drin haben und daraus automatisch ihre Konfiguration laden? W.S. schrieb: > µC, die als LCD-Treiber mißbraucht werden, was zwar irgendwie > hinzukriegen ist, aber dennoch keinen echten Nutzwert hat. Ich denke, das du das nicht meints, aber ich hatte von Pollin ein paar VFD's und hab passend in dessen Größe eine Platine mit einem PIC (macht aus Daten per SPI/I²C die Ansteuerung) und ein DC-DC + DC-AC Wandler, sodass man das Display relativ leicht mit 5V und SPI/I²C ansteuern kann. W.S. schrieb: > Oder Controller als DDS-IC, die zwar grottenschlecht sind im > Vergleich zu echten DDS-IC, aber dennoch erstaunlich beliebt. Ich müsste lügen, wenn ich sage, ich hätte nicht drüber nachgedacht. Allerdings nur relativ kurz, da ich merkte, dass das nicht so gut machbar ist. Auch nicht, wenn man nur eine viertel Periode speichert (einmal Hoch und runterfahren, danach nochmal, aber per extern zugeschalteten invertierer(OP) dann negativ), dann hätte man mit dem gleichen Speicher eine höhere Zeitliche Auflösung bei langsamen Frequenzen. Aber naja. Dann hab ich mir doch den DDS-Baustein von AD geholt ;) W.S. schrieb: > Ich frag mich aber bei dem TO, was er denn bislang an > Kreationen vollbracht hat u.A. eine BLDC Steuerung, Drehzahlmesser, Elektronische Last (µC gesteuert), Experimentierboards mit allerhand Sachen drauf, RBG-LED-Treiber, ... Im Moment hab ich 2 Projekte am Laufen (ich brauch immer mehreres Gleichzeitig, dass ich eine Alternative habe, wenn ich auf eine Sache mal keine Lust habe): - Ein via Encoder/USB einstellbares, µC gesteuertes und OPV geregeltes Doppelnetzteil (2x 20V/5A) inkl 3.3V/2A, 5V/3A und 12V/2A Festspannungsausgang. - Quadrokopter (allerdings noch relativ am Anfang) - neue, größere el. Last (Basis PIC18F/MAX1342) W.S. schrieb: > und was er mit einer neuen > Beschäftigung mit nem ARM oder nem FPGA erzielen will? Vorrangig will ich es lernen, dass, wenn mir doch irgendwann ein Projekt in den Sinn kommt (Wie z.B. so ein Self-Made Oszi oder ein LA, der ohne USB/PC funktioniert), ich nicht erstmal einige Wochen/Monate lernen brauch, soetwas zu benutzen. Also quasi eine Präventiv-Maßnahme. Außerdem bin ich von solchen programmierbaren Bausteinen recht begeistert und es interessiert mich im Allgemeinen sehr (manchmal zum "Leidwesen" meiner Freundin ;) ).
ich schrieb: > Das ist ja ein wenig mein Problem, dass ich die Grenzen nicht genau > sehe, also was besser für was ist. Hallo "ich", Wie ich es bisher erlebt habe: uP/uC: Alles was mit normaler Peripherie (Zähler, AD, DA, Timer, Schnittstellen, ...) bis zu einer gewissen Geschwindigkeit mit der onboard Peripherie gemacht werden kann. Das kann von Familie zu Familie stark schwanken. z.B. hat TI uCs die sie DSPs nennen, für Motorsteuerung gedacht sind, ADs mit 3...6MS/s bei 10bit an Board haben. Da kann man deutlich mehr machen als mit den STM ADs der STM32F ARM Familie. Umgekehrt haben die STM32 ARMs bessere Kommunikation mit an Board und DMA die schon mal für clevere Sachen missbraucht werden kann. Irgendwann sind die Peripherien nicht mehr schnell genug. Dann brauchst Du z.B. etwas Glue-Logic um andere Peripherie anzsuchließen oder die Daten extern vorzuverarbeiten. Hier könnten CPLDs mit geringen Kosten und wenig Logikblöcken ein durchaus interessante Brücke sein. In alten kleinen CPLDs habe ich schon ganze DRAM-Controller gebaut, Burstfähig und mit speziellen Refresh-Algortihmen. Wenn dann das nicht mehr reicht, du z.B. mehrere CPLDs benötigtest oder du ganz neue Peripheriebausteine selbst zimmern müsstets dann kommen FPGAs in's Spiel. Da kannst Du dann evtl sogar einen Teil der Datenberarbeitung bereits vollständig erledigen da Du dort hohe Komplexität mit reinpacken kannst oder eine kleine "CPUs" mit reinpacken kannst (muss ja kein Pentium sein aber z.B. eine schnelle 32-bit Mickroslice/DSP mit geringem Befehlsumfang die sich umprogrammieren lässt). Brauchst Du aber am besten VHDL. Haben wir schon mal einen kompletten Steuerchip für eine SSD mit ECC und mehr drinnen realisiert. War halt die Geschwindigkeite die nötig war. rgds
ich schrieb: > Gibt es nicht auch FPGAs, die einen Flash- oder RAM-Speicher drin haben > und daraus automatisch ihre Konfiguration laden? Flash: Nein SRAM: Ja aber nicht für die Konfiguration ich schrieb: > Kreationen vollbracht hat Bei dem was Du bisher gemacht hast und bei dem Was Dir vorschwebt würde ich denken, dass Du bei ARM besser aufgehoben bist. Da bist Du bei weitem flexibler und hast gleichzeitig mehr Pripherie an Board, brauchst also "nur" die SW richtig stricken :) . Bis du einen STM32F407 mit 168MHz erst mal voll ausgereizt hast vergeht eine Zeit. Bis dahin ist die Nächste Generation auf dem Tisch, da reden wir dann über 200+ MHz. Wenn Du dann tatsächlich Bedarf hast, mehr Daten noch schneller zu verarbeiten und den ARM unter Kontrolle hast kannst DU mit FPGA oder CPLD weitermachen. Bei Bedarf auch gleichzeitig. rgds
6A66 schrieb: > z.B. hat TI uCs die sie DSPs nennen, für Motorsteuerung > gedacht sind, ADs mit 3...6MS/s bei 10bit an Board haben. jo, die dsPICs haben max 4MSPS bei 10bit. Ich hab nochmal eine Frage zu einem Satz aus dem CPLD-Artikel: "CPLDs enthalten wie die kleineren GALs eine Und-Oder-Matrix sowie Speicherelemente (FlipFlops, Abk. FF), die frei miteinander verbunden werden können." Als Beispiel, ich Programmiere als Schematic für den CPLD einen simplen Counter. Ist es dann nicht so, dass die Und-Oder-Matrix die Verbindung von den Pins zu den Counter "macht" und die FlipFlops so zusammengeschaltet werden, dass ein Counter daraus entsteht? Dann schließe ich als folgenden Sätzen: "Die Anzahl der FFs ist fest an die Anzahl der User-I/O gekoppelt. Meist steht für ein Pin ein bis zwei FFs zur Verfügung." Wenn ich einen CPLD in einem DIP40-Gehäuse habe und davon Beispielsweise 36 IOs sind, dass ich (mit 1 FF pro IO) für den Counter maximal 36 Flipflops zur Verfügung habe, demnach für 4 Counter jeweils 9 FFs?
ich schrieb: > Beim ARM schwebte mir etwas mit Linux vor.. Aber ein Board mit einem Linux.. und dann? Tja, eben. Was dann? Siehste, am Anfang steht die Anwendung und nicht ein BS. Aber bleib mal auf dem Teppich: aktuelle ARM's und Cortexe mit MMU (die man ja sowohl für Linux als auch für WinCE braucht) sind heutzutage nicht mehr in bastel-lötbaren Gehäusen zu haben, da sind BGA's angesagt, genauso wie bei den ja ebenfalls erforderlichen RAM's (SDRAM, DDRAM, LPDDRAM...) - und das zieht automatisch ne recht anspruchsvolle mehrlagige LP nach sich. Natürlich kann man auch mit nem gekauften Board herumdaddeln, aber das ist in letzter Konsequenz völlig hardware-fern. Ob man da irgendwas auf dem PC macht oder auf nem Board wie dem Raspberry oder auf ner Box wie der PNXdingsda von Pollin, ist da eigentlich völlig egal. Ist halt App-Programmierung auf einem BS. Wenn du aber tatsächlich mit Hardware umgehen willst (was ich mal annehme), dann wirst du auf den bastlergeeigneten ARMS/Cortexe kein Linux drauf haben - wozu auch? Wer mit Linux herumlinuxen will, ist mit einem PC besser bedient und wer mit der Hardware umgehen will und was draus machen will, kommt zumeist auch ohne ein dickes BS aus. Ich geb dir mal ein paar Beispiele: a) ein LPC2478 oder ein dazu pinkompatibler Typ mit 8 ode 16 MB externem SDRAM und TFT-Display dran (sinnvoll: maximal 800x480), dazu ne SD-Fassung, ein CODEC dazu und einige Leitungen für bedienelemente. Wenn habbar, dann auch Touch. Das Ganze als Frontplatte für ne Kiste, die als Kennlinienschreiber, einfacher NF-Oszi, NF-Signalgenerator, Display für nen Wobbler, usw. fungieren kann. Mit etwas TTL oder nem kleinen CPLD auch als Nobel-Frequenzzähler. Also was zum Anreichern des Bastelkellers. b) dasselbe, aber mit nem STM32F10xxx.. und eben nur mit statischem RAM, dafür ein CPLD (95144 reicht), was zusammen mit nem schnellen 256x16 oder 512x16 SRAM als LCD-Controller dient. Hier kannst du dann beides üben: µC und CPLD. c) ein ganz kleiner ARM (sowas wie ein LPC2103) mit nem kleinen monochromen Grafikdisplay, nem 20 ..24 Bit ADC, Drehgeber, ein paar Tasten als Kistchen, was für die Küche ein PT100-Thermometer ist mit zusätzlichem Counter als Eieruhr usw. Über sowas freuen sich auch die Frauen. ich schrieb: > Als Beispiel, ich Programmiere als Schematic für den CPLD einen simplen > Counter. Unteschätze mal die CPLD's nicht. Damit kann man sehr viel mehr machen als nur nen simplen Counter - und die E/A sind den Macrozellen nicht 1:1 zugeordnet. Und schnell sind einige Familien auch. Die Coolrunner sind intern für bis zu 600 MHz gut (schnellste Version). W.S.
W.S. schrieb: > Aber bleib mal auf dem Teppich: aktuelle ARM's und Cortexe mit MMU (die > man ja sowohl für Linux als auch für WinCE braucht) sind heutzutage > nicht mehr in bastel-lötbaren Gehäusen zu haben, da sind BGA's angesagt, > genauso wie bei den ja ebenfalls erforderlichen RAM's (SDRAM, DDRAM, > LPDDRAM...) - und das zieht automatisch ne recht anspruchsvolle > mehrlagige LP nach sich. Da hast du wohl recht. Hab ich nicht so dran gedacht. Vorschlag a) und c) klingen recht interessant. Aber soeine EierUhr/Thermometer ist ja ansich auch mit nem 8bit, wenn nicht 16bit PIC machbar, aber als Einsteigerprojekt für nen ARM bestimmt nett. W.S. schrieb: > Unteschätze mal die CPLD's nicht. Vielleicht tu ich das sogar. Ich hab schon manches gesehen, was andere damit gezaubert haben, aber der CPLD-Artikel hier auf der Seite macht nicht umbedingt Werbung, finde ich. Ich mein, ein Artikel soll natürlich Sachlich sein, aber das Einzige, was ich darin an "Pluspunkten" gefunden habe (also nicht neutral oder Nachteil war), war das schnelle Starten dank internem Speicher und durch die Einfachheit vom Aufbau besser abschätzbare Laufzeiten. W.S. schrieb: > Damit kann man sehr viel mehr machen > als nur nen simplen Counter - und die E/A sind den Macrozellen nicht 1:1 > zugeordnet. So war das nicht gemeint. Sondern als Frage, ob ich das Prinzip richtig verstanden habe.
ich schrieb: > "Pluspunkten" gefunden > habe (also nicht neutral oder Nachteil war), war das schnelle Starten > dank internem Speicher und durch die Einfachheit vom Aufbau besser > abschätzbare Laufzeiten. Hallo "ich", das sind u.U. gerade die Faktoren die das System benötigt. Denk an den DRAM-Controller den ich erwähnt habe habe. Deterministische Zeiten waren extrem wichtig und das System musste sofort nach Betriebsspannung laufen. Seienerzeit haben wir auch was (in der Nachbarabteilung) mit FPGA gemacht, da musste ich mal aushelfen. Das war echt PITA (google). Das war so voll dass jedesmal wenn eine kleine Funktion geändert werden musste entweder das Timing nicht mehr haltbar war oder die I/Os sich verändert haben. Sicher hat sich da viel verändert bis heute (>10a) und das Design war auch hoffnungslos überladen. Aber ich habe da was darus mitgenommen was Deiner Aussage in etwa entspricht: Platz vorhalten und Zeitreserven (Laufzeiten im FPGA) mit einplanen. das ist aber bei Bastelprojekten nicht so kritisch. Wenn Du VIEL an zusätzlicher Logik machen willst wirst du um's FPGA nicht rumkommen. Ist aber IMHO nachrangig. rgds
6A66 schrieb: > oder die I/Os sich verändert haben. Ich dachte, die kann man frei auswählen!? Das mit der Laufzeit leuchtet mir ein, doch heutzutage werden doch eher FPGAs (u.a. dann auch zur Ansteuerung von DDRAM) eingesetzt. Zudem "stören" mich ebi CPLD 2 Dinge: 1. Bei Digikey fangen die FPGAs bei einem kleineren Preis an wie CPLDs 2. Lothar Miller schrieb: > Und zudem (du willst ja was Neues lernen) sind CPLDs sogar vom > eigentlichen CPLD-Erfinder Lattice inzwischen für nicht überlebensfähig > erklärt worden: Lattice verkauft seine "kleinen" FPGAs unter dem > Deckmäntelchen CPLD, um potentielle Umsteiger nicht abzuschrecken... Wenn ich mir also statt einem "echten" CPLD sowieso ein FPGA kaufe, macht es doch auch keinen Sinn. CPLD scheinen "einfacher", ich hab aber auch ein kleines FPGA-Board zuhause.. Ich hab mich auch nochmal mehr bei ARMs umgeguckt. Ich hab ein STM32F4Discovery, doch ich bin mir noch nicht sicher, ob STM32F2..., STM32F4... oder LPC17..., LPC18... Man, so ne riesen Auswahl is doch kacke ;)
W.S. schrieb: > Aber bleib mal auf dem Teppich: aktuelle ARM's und Cortexe mit MMU (die > man ja sowohl für Linux als auch für WinCE braucht) sind heutzutage > nicht mehr in bastel-lötbaren Gehäusen zu haben, da sind BGA's angesagt, > genauso wie bei den ja ebenfalls erforderlichen RAM's (SDRAM, DDRAM, > LPDDRAM...) - und das zieht automatisch ne recht anspruchsvolle > mehrlagige LP nach sich. Naja, das ist nur halb richtig. Es gibt auch Cortex-M im TQFP (mal bei Olimex schauen, die verbauen so was), oder Daughterboards, die Controller+Versorgung+RAM an Bord haben, zu denen man aber noch jede Menge Peripherie stricken kann. Mit dem hier im Forum beliebten DIL und anderen bedrahteten Senioren hat das aber nicht mehr viel zu tun. Ist halt näher an professioneller Arbeit als an Basteln. Ob das ein Nachteil ist, muss jeder für sich wissen. Max
Ja die Preise sind schon geil bei den FPGAs. bei so ca. 30000€ pro FPGA kommt dann nen Panzerwagen vorbei wenn du 1000 Stück bestellst. 30 Milionen € ist schon nen Wort.
ich schrieb: > die kann man frei auswählen!? Tja, nur wenn Du am Anfang bist und noch keine fertige Schaltung hast Die Du noch korrigieren willst aber das PCB schon seit langem steht. Fang halt mal an z.B. mit nem STM32F4x Discovery, kostet wenig, kann viel. Du kannsta uch noch 'n Jahr warten, dann gibts was Neues, und dann steht da wieder was vor der Tür, und.... rgds
Machs wie ich ... nimm einen Zynq dann musst du dich nie wieder entscheiden ;) Ok der AD/wandler ist zu langsam aber sonst hast du alles.
Uwe schrieb: > Ja die Preise sind schon geil bei den FPGAs. > bei so ca. 30000€ pro FPGA kommt dann nen Panzerwagen vorbei wenn du > 1000 Stück bestellst. Ach watt, einfach günstig per Hong-Kong Post und natürlich als "Gift" oder Warenwert $10 deklariert ;-)
Max G. schrieb: > Mit dem hier im Forum beliebten DIL und anderen bedrahteten Senioren hat > das aber nicht mehr viel zu tun. Ist halt näher an professioneller > Arbeit als an Basteln. Da hab ich nichts gegen. ICs in SOIC/SOT23/TQFP hab ich auch schon gelötet, TQFN/TSSOP kommt jetzt, wenn ich n paar Platinen bestelle (sonst hab ich in der Fachhochschule gefräst), dann auch mit Lötpaste und Hot-Air-Station. Ggf auch gleich 4-lagig (zum einfach-mal-gemacht-haben und ggf auch nötig;) ). Ist relativ günstig. 6A66 schrieb: > Fang halt mal an z.B. mit nem STM32F4x Discovery Hab ich zuhause ;) Hans-Georg Lehnard schrieb: > nimm einen Zynq dann musst du dich nie wieder entscheiden ;) Etwas über meinem Budget ;) Grendel schrieb: > Ach watt, einfach günstig per Hong-Kong Post und natürlich als "Gift" > oder Warenwert $10 deklariert ;-) xD, natürlich lose, ohne ESD-Hülle und von den 1000 bei 15 eine kleine Ecke abgebrochen =)
ich schrieb: > 6A66 schrieb: >> Fang halt mal an z.B. mit nem STM32F4x Discovery > > Hab ich zuhause ;) Ahh nein. Es ist doch "nur" ein STM32 Discovery mit einem STM32F1 drauf
Angehängte Dateien:
-
Evalboard.jpg
85 KB
ich schrieb: > Vorschlag a) und c) klingen recht interessant. Aber soeine > EierUhr/Thermometer ist ja ansich auch mit nem 8bit, wenn nicht 16bit > PIC machbar, aber als Einsteigerprojekt für nen ARM bestimmt nett. klar, 1000 Wege führen nach Rom. Aber bei allen kleineren µC hat man immer das Problem, daß man nach einem suchen muß, der genug RAM hat. Jaja, ich hab auch schon mal ein ALPS LSU.. (von Pollin) an einen PIC16F873 angeschlossen. Geht, aber ist eigentlich Unsinn. Viele Leute auch hier in diesem Forum glauben, daß man ja nur ein Grafik-LCD irgendwie an seinen Controller physisch dranferkeln muß und schon sind alle Probleme gelöst. Denkste, da fangen die erst an. Man will ja auch was darstellen auf dem Display und wenn man das mit Setzen von Pixeln in einem externen LCD versucht, kommt ne Schnecke bei heraus. Also ist angesagt, das Gesamtbild im RAM aufzubauen und dann en bloc in das Display zu hieven - tja und da kommt Bedarf an ausreichend RAM auf, den viele kleinere Controller schlichtweg nicht haben. Bei bunten Displays so ab QVGA kommt noch hinzu, daß die schiere Größe des erforderlichen Bildspeichers oftmals den verfügbaren Adreßraum des µC übersteigt. Deshalb predige ich hier seit einiger Zeit (wie ne tibetanischen Gebetsmühle), "Nehmt nen ARM, da habt ihr Adreßraum reichlich und wenn es einer mit herausgeführtem Bus ist, dann klemmt noch ne Breitseite RAM dran, man ist später froh drüber". Ich hänge mal ein Bild von nem Eigenbau-Evalboard dran: STM32F103ZET6 (Mitte) plus 2 MB RAM (links) plus Xilinx-Coolrunner (links oben) für's Display UND für noch ne Reihe Reserve-I/O's (der RAM daneben ist der Bildspeicher) plus SD-Karte plus CODEC, (der unbestückte Platz ist für nen UKW-IC von SiliconLabs) plus UART's plus reichlich I/O usw. Sowas kann man sich selber designen und dann bei den einschlägigen Leiterplattenfirmen anfertigen lassen - und selber löten geht auch noch, sind ja keine BGA's dabei. Für den Anfang rate ich dir, mal das "Lernbetty"-Projekt hier aus der Codesammlung runterzuladen und ein bissel hineinzuschauen. Ich denk mal, mit so einer Swissbetty von Pollin (wenn's die noch gibt) ist man auf den Anfang deutlich besser bedient als z.B. mit dem hier vielgepriesenen STM32-Discovery. Das ist nämlich ziemlich nackig, außer Prozessor fast nix drauf. Genau deshalb finde ich dieses Discovery auch überhaupt nicht gut. Klar, man kann es benutzen, um den Umgang mit dem Debugger zu erlernen, aber für irgendwas Nützliches ist es herzlich ungeeignet. Da wäre es fast besser, den µC runterzulöten und sich ne eigene Platte zu designen - aber auch dafür taugt es nicht, denn dem Chip fehlt der herausgeführte Systembus. Bei der Betty hat man wenigstens gleich am Anfang ein Grafikdisplay, Tasten und ne einfache Audioausgabe - abgesehen von dem IR- und HF-Zeug. Und sie kostet fast nix. W.S.
W.S. schrieb: > Klar, man kann es benutzen, um den Umgang mit dem Debugger zu > erlernen, aber für irgendwas Nützliches ist es herzlich ungeeignet. Da > wäre es fast besser, den µC runterzulöten und sich ne eigene Platte zu > designen - aber auch dafür taugt es nicht, denn dem Chip fehlt der > herausgeführte Systembus. Hallo W.S. klar, das STM32F4 Discovery ist etwas nackig. Aber es hat alles was man für den Anfang braucht: Den Debuggeranschluss, Stromversorgung, USB, und die ganzen Pins gausgelegt. Wer mehr möchte kann zwei Wege beschreiten: a) Eigene Peripherie an das Dicovery dranfrickeln - für die Bastler mit weniger Budget gut machbar. b) ein größeres EVAL (OLimex, ....) kaufen, evtl auch mit CPLD/FPGA und dann mehr machen. Wer noch besser im Futter (Geld, Zeit, Fähigkeiten) steht macht sich sein eigenes Board gleich selbst. Davon gehe ich aber beim TO nicht aus. Da er auch noch unsicher ist und er schon Erfahrung im Bau hat hatte ich an das stm32f4 discovery gedacht. Lernkurve steil, wenn's dann zu klein wird sind halt nur 10EUR weg, auch wenn's die falsche Richtung ist. Und wenn die Lernkurve abflacht und es ist die richtige Richtung ist dann schnell ein komplexeres Board beschaftt. Aber mit Komplex anfangen ???? rgds
Du meine Güte. Ich seh hier nix konkretes was den gesteigerten Aufwand mit ARM oder gar FPGA rechtfertigt. Alles auch mit AVR/PIC realisierbar. Hier hingegen reichlich vertreten ist Technikverliebtheit und allerhand Geprotze... Mensch Leute denkt von der geplanten Anwendung her und mit welcher Hardware die möglichst einfach und stromsparend umzusetzen ist. Ich glaube das dürfte bei der überwiegenden Mehrheit der Projekte hier eben gerade nicht auf ARM und FPGA hinauslaufen!
W.S. schrieb: > Aber bei allen kleineren µC hat man > immer das Problem, daß man nach einem suchen muß, der genug RAM hat. > Jaja, ich hab auch schon mal ein ALPS LSU.. (von Pollin) an einen > PIC16F873 angeschlossen. Grade bei PICs hat man doch so viel Auswahl. Den PIC16F873 hab ich zwar nicht gefunden, doch wenns (durch n Tippfehler) der 883 war... der hat ja auch nur 256Byte RAM.. Es gibt auch welche mit 2kB und das is nur PIC16 (PIC18 bis 4kB). W.S. schrieb: > Deshalb predige ich hier seit einiger Zeit (wie ne tibetanischen > Gebetsmühle), "Nehmt nen ARM, da habt ihr Adreßraum reichlich und wenn > es einer mit herausgeführtem Bus ist, dann klemmt noch ne Breitseite RAM > dran, man ist später froh drüber". Ich bin aber eher einer der Fraktion "Ich such mir den passenden µC für die Anwendung" ;) Klar kann ich (wenn ichs iwann beherrsche) n ARM nehmen und auch noch extra RAM dranbauen, doch für eine simple Küchenuhr ist das einfach deutlich Overkill. Ich würde das auch nur des Lernzwecks machen. W.S. schrieb: > Ich denk mal, > mit so einer Swissbetty von Pollin (wenn's die noch gibt) ist man auf > den Anfang deutlich besser bedient als z.B. mit dem hier vielgepriesenen > STM32-Discovery. Swissbetty hab ich nich gesehen. Nur die Universalfernbedienung BETTY (passt mir Tasten und LCD). Aber ein Programmer brauch ich dann auch noch (ist auf dem Discovery drauf). Ne USB-Buchse ist denke ich auch nicht mit in der Fernbedienung. 6A66 schrieb: > Wer noch besser im Futter (Geld, Zeit, Fähigkeiten) steht macht sich > sein eigenes Board gleich selbst. Davon gehe ich aber beim TO nicht aus. Ich hab mir sowas in der Art für PICs mal gemacht.. Mit LEDs, Relais, Tastenfeld, Taster, EEPROM, DAC, ADC usw. Habe auch zusetzlich zu den PortPins auch nochmal extra die I²C/SPI/CCP Pins zusammengeführt. Ich hab aber nen ARM noch nie Aufgebaut, daher wird das eher das "Problem" sein, aber im Grunde machbar. Mops Fidibus schrieb: > Ich seh hier nix konkretes was den gesteigerten Aufwand > mit ARM oder gar FPGA rechtfertigt. Alles auch mit AVR/PIC realisierbar. Naja, ein (zumindest einigermaßen) brauchbares kleines Oszi, Logikanalyser, selbstgemachter MP3-Player der MP3s von SD-Karte, USB-Stick oder interner HDD liest (ein erstmal aufgeschobenes Projekt, das noch beliebig aufgebohrt werden kann), ... Aber was es auf jedenfall rechtfertigt ist das praxisnahe Selbststudium der Teile ;)
ich schrieb: > Ich hab mir sowas in der Art für PICs mal gemacht.. Mit LEDs, Relais, > Tastenfeld, Taster, EEPROM, DAC, ADC usw. Habe auch zusetzlich zu den > PortPins auch nochmal extra die I²C/SPI/CCP Pins zusammengeführt. Ich > hab aber nen ARM noch nie Aufgebaut, daher wird das eher das "Problem" > sein, aber im Grunde machbar. Ist auch nicht anders. rgds
Angehängte Dateien:
-
PIC16F871.jpg
130 KB
ich schrieb: > Den PIC16F873 hab ich zwar > nicht gefunden, doch wenns (durch n Tippfehler) Ja, Tippfehler, es war ein PIC16F871. Siehe Bild. ich schrieb: > Swissbetty hab ich nich gesehen. Nur die Universalfernbedienung BETTY Ja, eben die. Das was Pollin derzeit anbietet, ist die Swissbetty. "http://www.pollin.de/shop/dt/NzE4OTczOTk-/HiFi_Car_HiFi_Video_TV/TV/Fernbedienungen/Universal_Fernbedienung_BETTY.html"; Und für die Küchenuhr mit Thermometer hast du natürlich Recht. Sowas hab ich mit nem AD7714 und nem LPC2103 gebastelt, dessen (immer noch schmaler) RAM hatte grad so ausgereicht. GDI und Fonts sind wie bei der Lernbetty, ich hatte mir bloß auf Wunsch der Göttergattin nen deutlich größeren Font für die Temperaturanzeige kreiert. Der Sinn eines reichlicher ausgestatteten Evalboards ist aber eigentlich, daß es auch noch dann zu was nütze sein soll, wenn man die einschlägigen Peripherien kennengelernt hat - und da sind alle Evalboards ohne Display einfach Mist weil zu mager. Man kann natürlich als Minimallösung ein Alpha dranhängen, sowas geht ja eigentlich immer, aber das ist nicht die Kür. Deshalb ganz am Anfang schon über ne spätere finale Verwendung nachdenken. W.S.
W.S. schrieb: > wenn > es einer mit herausgeführtem Bus ist, dann klemmt noch ne Breitseite RAM > dran, man ist später froh drüber". Zu Zeiten eines Z80 und ähnlichen war das noch anders, aber heute dürfte der überwiegende Teil der Teilnehmer im Forum noch nie im Leben einen Systembus gesehen haben, übliche µC haben nur noch I/O-Pins. Daher kommen dann auch solche Fragen wie "wie schliesse ich ein serielles EEProm an den Datenbus an" wenn doch mal eine Erweiterung nötig ist. Ich hoffe nur, dass sowas wie Daten- und Adressbus in der Ausbildung wenigstens noch kurz mal erwähnt wird, obwohl sie in freier Wildbahn fast ausgestorben sind. Gruss Reinhard
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.