Hi,

Warum neu erfinden.....gibt doch genug anleitungen, z.b.:

http://www.mikrocontroller.net/articles/LED_cube

Gruß

Sash

Die habe ich auch schon gefunden .
Nur traue ich mich noch nicht an den 8x8x8 dran
Orientiert habe ich mich für den 3x3x3 an diesen beiden
http://www.ledstyles.de/ftopic5912.html?…=3x3x3+led+cube
und
http://www.ledstyles.de/fpost202323.html…cube#post202323
(der Schaltplan ist ganz unten )

Ich weis nich wie hoch dein Buget ist. Aber für den Anfang würde ich vielleicht so etwas nehmen:
http://www.pollin.de/shop/dt/MTY5OTgxOTk…_1_Bausatz.html

Je nach dem in welche richtung du dich entwickeln willst würde ich das Aktuelle AVRstudio 5 nehmen und es mal direkt mit C und einem der Beispiele testen.
Da kannst du dann auch mal erste erfahrungen machen und eine LED blinken lassen + Testen. Da kannst du Dir wenigstends sicher seind as die HW geht und es nur an der Firmware liegt.

Wenn du zu viele schritte auf einmal machst wird das warscheinlich schief gehen und du schmeisst das frustriert in die ecke.

Generell: wenn Du Dich mit dem Kram selbst beschäftigen willst, bin zumindest ich bereit, ab und zu mal was dazu zu sagen - wenn Du so'n anderes Projekt nur nachbauen willst kannst Du das gern tun, wirst hier auch sicher ein paar Kritikpunkte oder Tips erhalten, aber in C-Code arbeite ich mich nicht ein, und wenn Du ein fertiges Programm übernimmst, muß auch die Schaltung so übernommen werden (manchmal könnte vielleicht der sourcecode amgepaßt werden, aber...)
nochmal zu 1: ist nicht ganz so. Stellen wir uns den Würfel mal so vor, daß jeder Transistor eine Ebene nach Gnd zieht, und jede Säule durch einen µC-Pin versorgt werden kann. Dann würde der Ablauf so sein: alle Transistoren sperren (entsprechender Pin ist low)->dann Muster der nächsten Ebene durch high an den Säulenpins -> den entsprechenden Transistor (einen!!) durchschalten
Über einen timer kannst Du das ganze dann durch die Ebenen schalten lassen. Dadurch hast Du ein statisches (3D)-Bild. Wenn da noch irgendwelche Veränderungen/Animationen oder so rein sollen, müssen die in den 3 Ebenenmustern umgesetzt werden. Wobei 9bits in einer Ebene doof sind...
2: Du wirst den sicher Sockeln wollen (dann könnte man auch später noch extern flashen)
3: Wenn Du die ISP (SPI)-Pins in der Schaltung auch anderweitig verwendest, mußt Du beachten, daß einerseits die Pins beim Programmieren tanzen (also an den 3 Pins würden zeitweise hi-Pegel anliegen) -> könnte also unerwünschte Effekte auf den Rest der Schaltung haben, und andererseits könnte die Schaltung die Kommunikation stören (zB wenn der Programmer die entsprechenden Pegel nicht mehr sauber erzeugen kann, weil die Schaltung den grad woanders hin zieht, klar?
Das sind keine generellen Probleme, man muß halt nur drauf achten (bei Deiner Schaltung sollten zB die Transistoren Pulldowns an der Basis bekommen, damit die sicher Sperren, wen der µC-Pin Tristate ist (Reset)).
4.: Ich würde den 88 nehmen. Ein 8 macht das auch. Aber wenn man den sockelt kann man den auch wiederverwenden, für anspruchsvollere (insbes. HardWare) Dinge. Und die paar Cent... Ausserdem hab ich mir mal das DB des 88 ausgedruckt (bin halt ein Haptiker) - bei ~350 Seiten brauch ich das nicht nochmal... Aber Du kannst natürlich gern beim 8er bleiben...
6.: Ordentlich ist das natürlich mit Pullup, und der Pin selbst muß auch mit auf den ISP-Header
7.: Die µC-Pins können 4 Zustände annehmen. Als "Eingang" kann er entweder dermaßen hochohmig sein, daß er für die restliche schaltung quasi nicht existent ist ("offfen"/n.c.), oder über einen Pullup (ca 50KOhm oder so) "hochgezogen" (dann kann man da zwar 'n high-Pegel messen, aber der läßt sich auch einfach extern "runterziehen"). Als Ausgang (und das ist das, was Dich interessiert), kann er einen hi- oder lo-Pegel annehmen, und dabei (mit Einschränkungen) max. 20mA liefern oder schlucken.
Und wie kommt er auf diese Pegel? Indem er eben im µC auf Vcc oder Gnd geschaltet wird. Und PC3..PC0 werden halt auf AVcc oder AGnd geschaltet, wenn da also nix angeschlossen ist, kann auch an den Pins nix anliegen, klar?
Warum haben die 'ne seperate Versorgung? Weil der Controller an diesen Pins eben auch analoge Spannungen messen kann. Und in diesem Falle sollte dort die Spannung gefiltert werden (aber das is'n anderes Thema.
9.: paßt nicht zu meiner Aussage - der µC hat'n internen 8Mhz Oszillator für den Takt, man kann ihn aber auch mit 'ner externen Taktquelle versehen, max 20MHz beim Mega88. Der Quarz muß zwischen B6 und B7.
10.: UART ist eine serielle Kommunikationsschnittstelle, die im µC in Hardware zur Verfügung steht. Damit kann man dann einfach bytes zwischen µCs bzw µC und PC austauschen. Und weil der Mega das in Hardware hat, muß man sich nicht weiter um die umsetzung kümmern, sondern kann salopp gesagt ein Byte einfach "in den UART packen" oder da rausholen.
13.: war Quatsch, hatte ja oben schon was zu geschrieben -> dementsprechend würde ich mich bei der Pinbelegung noch nicht festlegen.
17.: Welches "Gerät" willst Du zum "brennen" verwenden, also welchen Programmer
Und nochmal allgemeines: Wenn Du Dich jetzt wirklich mit Mikrocontrollern beschäftigen willst (nicht nur als Nachbau von irgendwas), solltest Du erstmal mit was einfachem anfangen. (Breadboard, LEDs und so) Und das Cube-Projekt im Kopf behalten, das kommt dann schon noch.
Ansonsten braucht man eigentlich bei jedem Projekt das Datenblatt des verwendeten Controllers (Mega88) - solltest Du vielleicht ruhig ein paar mal durchgehen, auch wenn Du nicht (gleich) alles verstehen solltest. Fördert das allgemeine Verständnis von Mikrocontrollern ungemein.
Und dann kommts natürlich auch auf die Lieblings-Programmiersprache an. Meiner Meinung nach sollte das möglichst maschinennah erfolgen -> Assembler
Ein hervorragendes Tutorial (auch vom Stil her) dazu ist mMn dieses hier, was man sich ruhig mal in der Badewanne oder so durchlesen kann - lernt man viel über die Hardware
Wenn man AVR-Assembler programmiert, ist dies hier natürlich unverzichtbar...
BTT wären Schieberegister (serielle portexpander) eigentlich auch einen Blick wert. Der hier hat 16 Outputs, und ist kaskadierbar. Ansteuerung über SPI. (Und das is'n SOIC-24 mit 1.27mm Pinabstand...)
So, nun aber Sorry, für das viele OT

@LotadaC: nur mal so, um ne andere Meinung einzuholen: Worin siehst du den Vorteil von Assembler gegenüber C? Also ich kann beides so halbwegs, C geht mir aber deutlich leichter von der Hand. Gerade was Schleifen anbelangt ist C für meinen Geschmack umgänglicher. Shiften geht ja auch problemlos.
Und Verständnis dafür, was man da mit der ganzen Bitschubserei bewirken will, muss man bei beiden Sprachen haben.

Daß ich wirklich (!) weiß, was der Controller wann wie macht. (Im Prinzip programmierst Du damit ja 1:1 den Maschinencode, nur die Sprungdistanzen und so mußt Du eben nicht selbst ausrechnen). Insbesondere bei der Verwendung der prozessorinternen Hardware (die ja manchmal sehr prozessorspezifisch ist) und deren Initialisierung tun sich dann desöfteren Defizite auf (ja, ok, man kann die Register auch wieder zu Fuß erreichen, aber das ist ja dann Quasi Assembler ) Bascom zB. erlaubte mir die Auto-Triggerung des ADC durch einen überlaufenden Timer nicht. Ausserdem werden oft Register initialisiert, wo's nicht nötig ist (Stackpointer zB). Oder Quellcode direkt in die Interruptvectortabelle pressen.
Ich habe mich bei µC noch nicht mit C beschäftigt, insofern kann ich Deine Frage nicht wirklich beantworten. Wenns mal schnell gehen soll, und Effizienz keine Rolle spielt, hab ich früher halt auch mal Bascom genommen -> inzwischen bleibts aber eigentlich fast immer beim Assembler.

Zitat von »LotadaC«

Daß ich wirklich (!) weiß, was der Controller wann wie macht.

Dem muss ich wiedersprechen, gerade wenn das Projekt großer wird kommt optimiert der Compiler doch deutlich besser.
NUR bei zeitkritischen abläufen oder teilweise in IRQs nehme ich noch assembler. C Code ist auch deulich portabler, gerade wenn man zwischen mehreren Prozessorfamilien wechselt.
Aber ASM macht Sinn um grundsätzlich zu verstehen wie so ein Controller funktioniert, später kostet das meist nur unnötig Zeit und ist unnübersichtlich im vergleich zu C. Bei 95% aller Anwendungen ist es auch egal ob der C code 5% langsamer oder 10% mehr Speicher benötigt.
Dafür programmiert man C code meist um faktor 10 schneller als die gleiche funktionalität in ASM.
Speziell beim AVR kann man den C COde doch recht gut optimieren so das in den meisten fällen extrem guter Assemblercode bei rauskommt. Da kann man vom C Compiler noch was lernen wie man ASM schreibt .
Bascaom ist jetzt auch nicht unbedingt ne Referenz, der AVR GCC ist da sicher um einiges weiter was die OPtimierungen angeht. ABer auch bei C muss man wissen wie man es Programmieren muss damit der Compiler was vernünftiges draus bauen kann.

Zitat von »sebastian«

Dem muss ich wiedersprechen, gerade wenn das Projekt großer wird kommt optimiert der Compiler doch deutlich besser.

Das wurde ja auch gar nicht bestritten. Man weiß ja nicht, wie der Compiler optimiert. Insofern hat LotadaC ja recht: man kann nicht direkt beeinflussen, wann genau ein Befehl wie umgesetzt wird.
Aber wie Sebastian bereits sagte: Es kommt eigentlich äußerst selten auf eine etwas zügigere Abarbeitung an und deswegen hab ich nie verstanden, warum einem immer erst zu Assembler für den Einstieg geraten wird.

Könnte ich mir in C Rechenregister ... äh ... reservieren, um sie nur für bestimmte "Variablen/Konstanten" zu verwenden?
Werden "Zwischenergebnisse" im Register gelassen, oder werden die vor jedem Teilschritt aus dem SRAM geladen, und anschließend wieder dahin gespeichert?
Welche Rechenregister werden in den ISRs gesichert (Bascom AFAIK alle 32)? Oder nur die verwendeten? (Ich hatte schon kleine Programme, wo alles in Interrupts lief, und kein einziges Register gesichert werden mußte (da alle verwendeten Register halt reserviert waren) -> zu 99% hat der Controller geschlafen).
Meine Beobachtung ist, daß die Hochsprachen dazu verleiten, Probleme mittels oppulenter Software zu erschlagen, auch wenn es vielleicht 'n eleganten Weg mit der internen Hardware gibt. So werden zB UART oder SPI manchmal per SW konfiguriert (da gibts ja 'ne lib), ohne sich Gedanken darüber zu machen, daß der das in HW schon im Hintergrund abwickeln kann. Interruptbasiert und weitgehend selbständig. Oder bei wiederkehrenden ADC-Messungen wird im Timer-Interrupt der ADC gestartet, und dann das complete-flag gepollt.
Aber ich will hier niemanden überzeugen - das wesentliche war das mit dem grundsätzlichen HW-Verständnis.
Hier ist noch ein recht brauchbares Tutorial (insbes. zur Hardware und so).
Ansonsten noch der Hinweis, daß in den Tuts zT auf recht antiquierte Programmer und Software hingewiesen wird. Meiner Meinung nach reicht das AVRStudio vollkommen aus (inwiefern der neue integrierte C-Compiler brauchbar ist müssen andere (Sebastian?) beurteilen), als Programmer wäre der AVRISP MKII derzeit mein Tip (preislich auch ganz iO).

Hi,
Danke euch allen schonmal . Ich möchte nicht einfach nur stur nachbauen, sondern micht mit dem Theama selbst auch beschäftigen, da es mich sehr interessiert. Werde mir mal alles in ruhe durchlesen und behalte den Cube dann im Hinterkopf .
Ich werde mir dann wohl erstmal das Board, den Atmel ISP PRogrammer und einen Atmega 88 UND 8 zulegen. MfG
Sascha

Welches Board? Das von Sebastian verlinkte ist ein Bausatz. Da wär ich als Anfänger skeptisch (wenn was nicht geht, liegts am Board, oder am Programm etc...) Es verfügt über eine serielle Kommunikationsschnittstelle (zB zum PC - UART), eine SPI-Programmierschnittstelle (=Programmer), eine JTAG, ein paar Sockel für die verschiedenen verwendbare µC, und als Hardware zum Spielen dann 'n Summer, 3 Taster und 2 LEDs. Es erinnert auffällig an das STK500. Du brauchst am PC mindestens eine serielle Schnittstelle (RS232), ob das mit USB-Adaptern ordentlich läuft, weiß ich nicht. Das Programmieren (Hardware - also das Brennen in den Chip) übernimmt scheinbar das PonyProg - keine Ahnung, inwiefern die neue µC einpflegen (Stichworte TPI, PDI).
Meiner Meinung nach reicht für den Anfang auch'n Steckbrett mit'ner Hand voll Bauteilen, und dazu ein ISP-Programmer. Auch wenn es da diverse Nachbauten gibt (ich hab selbst zweimal einen USB-AVRISP-Klon nachgebaut), würde ich jetzt trotzdem zu einem Original Atmel-Programmer raten (Gründe wie oben). Später wird dann nur noch in der Zielhardware programmiert.

Zitat von »LotadaC«

ob das mit USB-Adaptern ordentlich läuft

läuft ordentlich. Zumindest mit dem STK500

Gut zu wissen, aber ich bezog mich auf den Pollin-Bausatz. Beim STK500 läuft die Programmierung ja irgendwie über den dort vorhandenen Megairgendwas, das Pollin-Board läuft direkt an der RS232. Was mich am STK500 immer genervt hat war entfernen der µCs aus den Sockeln (sitzen ziemlich fest drin, zT kein Platz zum vorsichtigen raushebeln usw - da wären so'ne Nullkraft-Sockel besser gewesen, aber preislich wohl nicht drin...). Zum Breadboard ist noch zu sagen, daß die üblicherweise keine Möglichkeit anbieten, so'ne 2reihige Stift-/Buchsenleiste irgendwie aufzunehmen (ISP) - die sind im wesentlichen für ICs gedacht -> Mindestbreite 7,62mm oder so. ich hab mir deswegen mal 'ne kleine Platine mit 'ner 2x5 Stiftleiste oben, und unten dran blanke Drahtenden, die in die entsprechenden Löcher im Board gehen. Einmal aufgesteckt halten die. (Hier is'ser mit drauf)

Mit dem Pollin-Board kann man entweder über RS232 oder über einen anzuschließenden ISP-Adapter proggen.

Ich persönlich z.B. habe genau das Board und schreibe / debugge dann mit dem AVR-Dragon die Megas.

Achso, eben mal in die Anleitung des Boards geschaut. Laut Schaltplan ist die ISP-Stiftleiste da oben wohl bidirektional. Man kann dort entweder einen externen ISP-progger anschließen (und die ICs in den Sockel proggen (also immer nur einen, klar)), dann sollte natürlich nix an die RS232-ISP - oder man kann dort einen externen µC anschließen, und den über die RS232-ISP "in circuit proggen" (dann sollte nix in den Sockeln sein). Ausserdem sollte man da auch an den HW-SPI rankommen.
@freakmaster: Was sind bei dieser Methode die Vorteile? Was spricht dagegen, direkt mit dem Dragon an die Zielhardware zu gehen? (platz des ISP-Connectors?, etwas mehr Layout-arbeit?, Andere HW an den Pins, die bedacht werden muß?)
Alternativ könnte man ja auch mal schnell 'n Wannenstecker (ISP-Header) an'n (Nullkraft-)IC-Sockel, sowie ein paar Kapazitäten und einen Quarz(-sockel)/Oszillator löten, wenn echtes ISP wirklich nicht möglich ist (und ein Breadboard zu störanfällig). Quasi ein Programmierboard Ultra-Light.
Ich persönlich benutze das STK500 praktisch überhaupt nicht mehr, seit ich die USB-AVRISPs habe.
Wie seht Ihr das?
Wer benutzt die "Spielmöglichkeiten" auf solchen Boards (LEDs, Taster usw)?
btw find ich den Schaltplan extrem unübersichtlich ->man kann doch Datenleitungen zum Bus zusammenfassen...

Zitat von »LotadaC«

@freakmaster: Was sind bei dieser Methode die Vorteile? Was spricht dagegen, direkt mit dem Dragon an die Zielhardware zu gehen? (platz des ISP-Connectors?, etwas mehr Layout-arbeit?, Andere HW an den Pins, die bedacht werden muß?)

Da gibt es einen ganz einfachen Grund: Bei den Sachen, die ich bisher entwickelt habe (das ist nicht arg viel bzw. hochkomplex ) habe ich die endgültige Platine immer erst nach "Abschluss" der Softwareentwicklung gebaut.
In der Zielhardware plane ich (mittlerweile) immer ISP mit ein!

Bei meiner ersten Schaltung hatte ich die ISP-Schnittstelle weggelassen und mich dann nachträglich so geärgert, dass am Tag danach eine neue Platine gefertigt wurde...

Ich benutze momentan den Dragon anstatt der RS232 nur, weil ich am Notebook keine COM-Schnittstelle mehr habe.
Auch habe ich den Dragon sehr günstig bekommen...

Zum "schnell was ausprobieren" ist die Platine schon ganz praktisch, wenn man kein Steckbrett hat bzw. nicht noch mehr Zeug in der Werkstatt herumfliegen soll (gerade am Anfang zum Lernen!).
Mit der Platine stößt man zwar auch relativ schnell an die Grenzen aber durch die 40er Leiste gibt es noch genug Ausbaumöglichkeiten. (siehe Erweiterungsplatinen von Pollin)

Hi,
Danke euch viiiiiiiieeeel mals (habe leider keine Aquadrops ) .
Als ISP USB "Adapter" werde ich mir diesen hier bestellen AVR STK500 V2.0 ISP(ich mag ebay.com ).
Das mit dem Board ist jetzt eine schwere Entscheidung, weil ich hir noch ein großes Bread Board rum liegen habe, was ich im moment eh nicht nutze .

Vorteil wäre, ich würde schon beim zusammenbau was lernen.
Nachteil, wenn etwas nicht funtzt, muss ich euch wieder belästigen .
Damit es auch funktioniert, was bräuchte man denn alles, um es auf dem Bread Board zum laufen zu kriegen? Also LED's habe ich noch hier bzw bestelle ich, als atmega nehme ich den 88er mit einem ic sockel. Irgendein altes PC Netzteil lässt sich mit sicherheit auch noch auftreiben .

Danke schonmal

MfG
Sascha

Zitat von »Dani D!«

@Sappibaer: Du bekommst das AVR STK500 V2.0 ISP bei Reichelt um den selben Preis nur noch kompakter!

Ich wollte eigentlich einen originalen von atmel haben, aber ich habe selbst gerade gelesen, dass der bei Ebay nur ein clone ist