Hallo liebes Forum, ich habe im Laufe meines Studiums bereits ein Betriebssystem mit Multitasking, Heap-Management, Shared-Memory, Externem RAM und Tastaturtreiber implementiert (alles auf AtMega644). Das hat mir mords-mäßigen Spaß gemacht. Leider ist dieses Semester nun beendet, ich würde aber gerne weiter an soetwas arbeiten. Der nächste Schritt wäre, Programme von einem Speichermedium in das RAM laden und dort ausführen (da fallen der AtMega und allgemein AVR leider raus, denn sie haben eine Harvard-Architektur). Da ich nun also sowieso nicht mit dem bekannten µC weiter machen kann, stellt sich mir dir Frage, warum nich ein eigenes Board nach meinen Wünschen aufbauen. Dazu brauche ich eure Hilfe. Mit welchem Chip ginge das am besten? Ich würde mich freuen, wenn er Code und Daten-Speicher nicht trennt, er intuitiv auf externen RAM zugreifen kann (um es einfacher zu machen) und etwas flotter als der AtMega644 bei 20MHz ist. 8 Bit wäre auch cool. Ich freue mich schon auf eure Antworten.
Die STM32F4 können genau das; deren ARMv7 -Architektur kann das mit dem Multitasking auch viel besser, weil genau darauf ausgelegt. Schau dir mal das STM32F4 Discovery Board an.
Kann dir zur Speicherarchitektur von ARMs nichts sagen, aber das ist wohl die nächste Liga. Denke in Zukunft wird es da ähnlich viele Projekte geben wie aktuell für die ATmegas.
@Hans (Gast) Danke für deine Hilfe. Du musst ja ein echter Hit auf Partys sein. @Dr. Sommer (Gast) Danke, das guck ich mir gleich mal an, sieht interessant aus. @Hui (Gast) Das sieht aus, wie ein bereits fertiges OS, aber das ist ja nicht, was ich möchte. Ich möchte das ja gerne selber benutzen.
Bei den ARM's hättest du definitiv auch einen Haufen Support hier aus dem Forum, was schon von Vorteil ist :)
Ich mache gerade genau das, was du machen willst, mit dem eZ80 von Zilog. (Genaugenommen mit dem EZ80F91AZA50, der hat schön viel peripherie, sogar Ethernet!) http://www.zilog.com/index.php?option=com_product&Itemid=26&task=parts&BL=1&familyId=130&productId=EZ80F91AZA Für die Grafikausgabe nehme ich das hier: http://excamera.com/sphinx/gameduino/ Macht ziemlich viel Spaß. Wenn ich fertig bin, gibt's das dann als Komplettbausatz :) Quellcode (Achtung, noch sehr experimentell!) hier: http://github.com/noah1989/eightzero Hier noch ein Video vom allerersten Versuchsaufbau, ich hab auch noch ein paar von den Platinen übrig: http://www.youtube.com/watch?v=cKoRRA4MyM4
@stefan_n Ich glaube dann habe ich deinen Post hier schonmal gesehen, denn dein video kenne ich schon =). Der Chip ist wirklich interessant und besonders der gameduino, wobei der ja doch etwas kostet ;). Hast du irgendwelche guten Links zu Seiten, die einem die Grundlagen für den Bau eines solchen Computers bereitstellen?
Gab hier mal eine Mehrkern-Microcontroller - Bestandsaufnahme . Beitrag "Mehrkern-Microcontroller - Bestandsaufnahme" Mit einem OS merkt man gar nicht, dass ein PC inzwischen mehrere Kerne hat. Aber Mehrkern-Mikrocontroller setzt keiner ein -- ohne OS zu aufwändig. Wie wäre es mit einem schlanken, einfach einzusetzenden Echtzeit-Betriebssystem für Mikrocontroller mit mehreren Kernen?
Niklas Rpunkt schrieb: > (da fallen der AtMega und allgemein AVR leider raus, denn sie haben eine > Harvard-Architektur) Da muss ich doch mal einwenden "All you need is AVR" ;-) Kann man auch ganze Computer draus bauen, nicht nur Code im RAM ausführen: http://www.mmk64.de Aber, auch wenn ein 6809-Interpreter eine schöne Umgebung für ein 8-bit-Multitaskingsystem ist, dürfte es wohl nicht deine Geschwindigkeitswünsche erreichen. Grüße Mark
Niklas Rpunkt schrieb: > @stefan_n > Ich glaube dann habe ich deinen Post hier schonmal gesehen, denn dein > video kenne ich schon =). Ich habe mal ein Video zur Platinenherstellung mit Lötstoplaminat hier eingestellt, wahrscheinlich bist du darüber dort hingekommen. > Der Chip ist wirklich interessant und besonders der gameduino, wobei der > ja doch etwas kostet ;). Das Gameduino-Board ist recht teuer (aber noch verkraftbar), aber open source, d.h. ich kann am Ende alles auf einer Platine integrieren. > Hast du irgendwelche guten Links zu Seiten, die einem die Grundlagen für > den Bau eines solchen Computers bereitstellen? Hm.. Mir fällt da spontan nichts ein (außer Wikipedia...). Das meiste Wissen habe ich aus dem Datenblatt. Wenn man weiß, was man zur Verfügung hat, ergibt sich der Bau des Computers eigentlich von selbst.
Niklas Rpunkt schrieb: > Hast du irgendwelche guten Links zu Seiten, die einem die Grundlagen für > den Bau eines solchen Computers bereitstellen? Nun ist mir doch noch was eingefallen: http://www.msarnoff.org/6809/ http://hive-project.de/
Ein Propeller ist doch im Endeffekt ein Mehrkern-uC.... Und es gibt AVR die externen Speicher ansprechen können (eben nicht alle), und die Harvard-Architektur lässt sich dann leicht umgehen indem man die Addressbereiche für beide Speicherarten einfach auf denselben Speicher mapt ;)
Andy D. schrieb: > und die Harvard-Architektur lässt sich dann leicht umgehen indem > man die Addressbereiche für beide Speicherarten einfach auf denselben > Speicher mapt ;) Da braucht man dann aber einen dual-port-RAM, sonst gibts nen Kurzschluss auf den Adress- und Datenleitungen, wenn gleichzeitig Befehle und Daten gelesen werden.
Ich finde das ein kleines bisschen frustrierend die ganzen fertigen Projekt schon zu sehen, die alle vor so viel Können strotzen, das ich mir noch aneignen muss. Ich glaube der eZ80F91AZA50SG ist eine gute Wahl. Zum einen freut es mich, dass er mit dem z80 verwandt ist und zum anderen ist er ein µC und kein µP. @stefan_n: Was genau hast du mit deinem Computer nachher vor alles zu tun? Mein Ziel ist es ein textuelles Terminal zu haben, aus dem heraus man alle möglichen Anwendungen (auch Grafikanwendungen) starten kann. Programmierst du das Ding in C? Wenn ja, mit welcher Umgebung? Und wie brennst du ihn? @Mark: Das sieht ja ganz nett aus, aber das ist mir dann schon eine Schicht zu abstrakt. Trotzdem danke.
Niklas Rpunkt schrieb: > Ich finde das ein kleines bisschen frustrierend die ganzen fertigen > Projekt schon zu sehen, die alle vor so viel Können strotzen, das ich > mir noch aneignen muss. Sieh es lieber als Beweis, dass es möglich ist. Wenn es andere schaffen, bekommst du das auch hin! > Ich glaube der eZ80F91AZA50SG ist eine gute Wahl. Zum einen freut es > mich, dass er mit dem z80 verwandt ist und zum anderen ist er ein µC und > kein µP. > > @stefan_n: > Was genau hast du mit deinem Computer nachher vor alles zu tun? Mein > Ziel ist es ein textuelles Terminal zu haben, aus dem heraus man alle > möglichen Anwendungen (auch Grafikanwendungen) starten kann. > Programmierst du das Ding in C? Wenn ja, mit welcher Umgebung? Und wie > brennst du ihn? Ich programmiere das Teil in Assembly mit dem Assembler z80asm aus dem z88dk. Es gibt auch einen C-Compiler, aber im Moment implementiere ich die lowlevel-Hardwareansteuerung, da nützt mir das nicht viel. Instruktionen die der Assembler nicht kennt werden einfach per DEFB reingehackt ;-) Anfangs hatte ich mir auch den SDCC angeschaut. Der kann zwar mehr, ist aber recht komplex und hat viele Abhängigkeiten, teilweise in verschieden Programmiersprachen. Beim z88dk sehe ich realistische Chancen, das Teil auf den eZ80-Rechner selbst zu portieren. Ich habe verschiedene Ideen, was man damit anstellen kann. Es soll ein Bausatz werden, mit dem man tolle Sachen machen kann wie mit Arduino, allerdings soll es ein eigenständiger Computer sein, den man komplett verstehen kann, so wie ein 80er-Jahre Heimcomputer. Natürlich dürfen auch Spiele nicht fehlen. Zum programmieren verwende ich das Zilog Debug Interface, ein einfaches serielles Protokoll. Auf dem Breadboard ist ein AVR, der über RS232 mit dem PC spricht und über ZDI mit dem eZ80. Damit bekomme ich Code in den RAM und debuggen geht auch. Mein aktuelles Ziel ist, das Monitorprogramm so weit zu bekommen, dass ich direkt Code über UART reinladen kann, sodass der AVR nicht mehr gebraucht wird. Dazu muss der Code dann natürlich auch in den Flash ROM. Ich empfehle allerdings dringend, das Datenblatt einmal komplett durchzulesen. Die Abschnitte zum ZDI und zum internen RAM habe ich ziemlich oft durchlesen müssen, bevor ich mir sicher war, wie ich es hinbekommen würde. Wenn man einmal verstanden hat, was die von einem wollen ist es nicht schwer, aber es sind schon ein paar Fallen eingebaut. Den Oszillator zum laufen zu bringen ist übrigens ein wenig komplizierter als bei einem AVR. Ohne den Widerstand von 100k parallel klappt es nicht. Ohne Oszilloskop wäre ich allerdings wahrscheinlich verzweifelt. Oft vergisst man Kleinigkeiten und es passiert auf den ersten Blick gar nichts. Ein Logikanalysator wäre wahrscheinlich noch nützlicher, auf jeden fall braucht man irgendwas, um sich die Signale anzuschauen, ansonsten ist man Blind und das macht keinen Spaß ;-)
@stefan_n nicht bei einem uC der nur einen Speicherbus hat :) Evtl denke ich mal wieder zu sehr in der 51er-Technik, aber da frühe AVRs mit externem Speicherbus eine elektrische Schnittstelle haben die in der Tat an den 51er angelehnt ist würde ich davon ausgehen dass die selbe Taktik wie bei 51ern dort funktionieren wird.
Stefan Noack schrieb: > Sieh es lieber als Beweis, dass es möglich ist. Wenn es andere schaffen, > bekommst du das auch hin! > So gesehen ist das natürlich auch schön =) Stefan Noack schrieb: > Ich programmiere das Teil in Assembly mit dem Assembler z80asm aus dem > z88dk. Es gibt auch einen C-Compiler, aber im Moment implementiere ich > die lowlevel-Hardwareansteuerung, da nützt mir das nicht viel. > Instruktionen die der Assembler nicht kennt werden einfach per DEFB > reingehackt ;-) > In der Uni haben wir es geschafft, das gesamte OS vollständig in C zu implementieren. Das hatte ich hier eigentlich auch vor. Aber ASM kann ich zur not ja auch :P Stefan Noack schrieb: > Ich empfehle allerdings dringend, das Datenblatt einmal komplett > durchzulesen. Die Abschnitte zum ZDI und zum internen RAM habe ich > ziemlich oft durchlesen müssen, bevor ich mir sicher war, wie ich es > hinbekommen würde. Wenn man einmal verstanden hat, was die von einem > wollen ist es nicht schwer, aber es sind schon ein paar Fallen > eingebaut. Den Oszillator zum laufen zu bringen ist übrigens ein wenig > komplizierter als bei einem AVR. Ohne den Widerstand von 100k parallel > klappt es nicht. > Okay das werde ich mir dann wohl noch zu Gemüte führen müssen. Das ist nur leider so trocken... und so lang... xD. Stört es bei dem Anschluss an die Pins nicht voll, dass ca. alle 8 Pins die Stromversorgung angeschlossen werden muss? Oder vertue ich mich gerade? So wie ich das sehe, muss doch überall wo V_DD und V_SS stehen die Betriebsspannung von außen angelegt werden oder? Stefan Noack schrieb: > Ohne Oszilloskop wäre ich allerdings wahrscheinlich verzweifelt. Oft > vergisst man Kleinigkeiten und es passiert auf den ersten Blick gar > nichts. Ein Logikanalysator wäre wahrscheinlich noch nützlicher, auf > jeden fall braucht man irgendwas, um sich die Signale anzuschauen, > ansonsten ist man Blind und das macht keinen Spaß ;-) > Oszilloskop steht mir nicht zur verfügung. Aber tun der µC und die Platinen ja auch noch nich^^. Ich werde mal gucken wie ich das regle. Zur Not verbrauchsarme LEDs zwischenklemmen.
Niklas Rpunkt schrieb: > In der Uni haben wir es geschafft, das gesamte OS vollständig in C zu > implementieren. Das hatte ich hier eigentlich auch vor. Aber ASM kann > ich zur not ja auch :P Wie habt ihr das geschafft? Stacks wechseln, und alle Register PUSH/POPen geht in C?
Niklas Rpunkt schrieb: > In der Uni haben wir es geschafft, das gesamte OS vollständig in C zu > implementieren. Das hatte ich hier eigentlich auch vor. Aber ASM kann > ich zur not ja auch :P > Für I/O und context switch braucht man aber trotzdem wenigstens ein bisschen ASM > Stört es bei dem Anschluss > an die Pins nicht voll, dass ca. alle 8 Pins die Stromversorgung > angeschlossen werden muss? Oder vertue ich mich gerade? So wie ich das > sehe, muss doch überall wo V_DD und V_SS stehen die Betriebsspannung von > außen angelegt werden oder? Da müssen nicht nur überall Anschlüsse hin, sondern auch noch Stützkondensatoren. von daher wird eine zweiseitige Platine gebraucht. > Oszilloskop steht mir nicht zur verfügung. Aber tun der µC und die > Platinen ja auch noch nich^^. Ich werde mal gucken wie ich das regle. > Zur Not verbrauchsarme LEDs zwischenklemmen. Eine Platine kann ich dir schicken (PM bei interesse), mein Oszilloskop nicht ;-) Den µC habe ich von Digikey, da gibts hier öfter Sammelbestellungen, wo man sich mit ranhängen kann.
Dr. Sommer schrieb: > Wie habt ihr das geschafft? Stacks wechseln, und alle Register > PUSH/POPen geht in C? Oh stimmt, dafür mussten wir uns ein Macro machen. Das ist mir entfallen, weil dieses assembler makro schon in einem Header war, als wir angefangen haben und ich es daher nich selber getippt habe. >Für I/O und context switch braucht man aber trotzdem wenigstens ein >bisschen ASM I/O ging komplett ohne, denn der Compiler kannte Begrifflicheiten wie PORTB und DDRD und so. >Da müssen nicht nur überall Anschlüsse hin, sondern auch noch >Stützkondensatoren. von daher wird eine zweiseitige Platine gebraucht. Oh man das klingt echt anstrengend^^ Ich höre nächstes Semester Elektrotechnik II, aber bis dahin hätte ich das schon gerne angefangen. >Eine Platine kann ich dir schicken (PM bei interesse), mein Oszilloskop >nicht ;-) Hehe danke. Das klingt verlockend. Ich informiere mich vorher noch genauer. Ich melde mich deshalb nochmal mit PM.
Hey, Ich kann dir sonst auch noch die AVR32 Kerne empfehlen. Sind zwar 32bit Architektur, aber du kannst sie ganz normal mit dem Atmel Studio Programmieren. Bei der Kernen gibt es verschiedene Varianten auch welche mit SDRAM Interface wo du z.B. 8-128 MB SDRAM anschließen kannst. Die Architektur ist keine Harvard mehr also nicht wie die normalen AVRs und Programme laufen Problemlos aus dem internen sowie externem RAM. Prozessor Geschwindigkeiten liegen bei 60-66 MHz. Kannst dir ja einfachmal den Text von Wikipedia ansehen.
@peterG Der AT32UC3A3256 sieht echt interessant aus, da er schon von Haus aus SD-Karten unterstützt. Gibt es eig. eine günstige Alternative zu JTAG? Ich habe selber keinen Brenner und damit auch nicht die Möglichkeit mir mal eben einen Brenner zu bauen. Ich möchte auch nicht Ewigkeiten damit aufwenden, selber einen Brenner herzustellen.
Die werden mit Bootloader ausgeliefert, brauchst nur USB schnittstelle herrausführen und schon kannst du sie Brennen. Kein JTAG oder so erforderlich, nur zum Debuggen wäre es trotzdem zu empfehlen. Es gibt AT32UC3A3 Boards mit SDRAM von Atmel für 40 Euro.
Ich als armer Student werde dann eher auf die USB-Schnittstelle zählen. Dann dauert das debuggen halt länger. Das Board muss ich mir unbedingt ansehen. Ich habe auch nach sowas gegooglet, aber nix gefunden. Wie hast du das gefunden? Wie hast du gesucht? Ich glaub ich suche falsch.
Hey, Ich meinte eigentlich das: http://www.watterott.com/de/Atmel-UC3-A3-Xplained-AT32UC3A3-XPLD Aber ich sehe, die haben keine mehr. Falls es günstig sein soll, kannst du zum Einstieg auch erstmal das hier kaufen: http://www.watterott.com/de/AVR32-PIKO-Board Hat leider nur kein SDRAM. Aber für den Anfang sind 96kbyte trozdem ganz OK, vorallem wenn du später dein eigenes Board machen willst, kannst du dann immernoch den UC3A3 nehmen.
Sorry dass ich mich so lange nicht gemeldet habe. Musste 2 Klausuren schreiben. Also, Ich glaube ich entscheide mich für dieses Evaluations-board: http://de.mouser.com/ProductDetail/Atmel/AT32UC3A3-XPLD/?qs=%2fha2pyFaduhsIwLAHwlNSTK32S8RDytWSfColjf%252bA005vesOLWQHq6frP210oKqU Dazu noch diesen SD-Karten adapter: http://www.shop.display3000.com/elektronikmodule/sd-speicherkartenplatine.html Und dann kommen die Fragen: Geht das mit dem Gameduino? Der braucht sehr viele Anschlüsse. Hast du da ein paar mehr infos zu stefan_n ? Die Tastatur sollte ja über PS\2 angeschlossen werden. Wo bekomme ich fertige Steckplatinen her? Kann mir da wer helfen?
Niklas Rpunkt schrieb: > > > Und dann kommen die Fragen: > Geht das mit dem Gameduino? Der braucht sehr viele Anschlüsse. Hast du > da ein paar mehr infos zu stefan_n ? Das sieht nur so aus wegen dem Shield-Format. Die meisten sind unbenutzt. Der braucht nur 3.3V und SPI (also SCK, MISO, MOSI und Slave Select) Guckst du hier: http://excamera.com/sphinx/gameduino/hardware.html Und hier: http://excamera.com/sphinx/gameduino/porting.html Das ist mein Code für die Ansteuerung. Wird dir zwar nicht viel nützen, aber vielleicht hilft es zur Inspiration: https://github.com/Noah1989/EightZero/blob/master/src/video.asm
Niklas Rpunkt schrieb: > Vielen Herzlichen Dank! > > Hast du denn eine Tastatur angeschlossen? Ja, über zwei General Purpose I/O pins. Ein Interrupt löst bei fallender CLK-Leitung aus und schiebt dann ein bit von der Datenleitung rein. Das Format ist Startbit, 8 Datenbits, 1 Paritätsbit, 1 Stopbit. Die Taktfrequenz mit der das Protokoll arbeitet ist angenehm langsam :) Allerdings läuft die Tastatur mit 5V, die Signale sind open collector (externe Pullups, die Teilnehmer ziehen nur nach 0V, niemals mit 5V treiben!) Wenn man 5V-Tolerante eingänge hat, geht es. Solange man nichts senden will muss man sich nicht viel Gedanken machen. Wenn man dann die Scancodes bekommt, muss man die noch vernünftig auswerten. Das ist auch lustig. Hier ist eine recht nützliche Seite: http://www.computer-engineering.org/ps2protocol/ Und hier ist meine Implementierung: https://github.com/Noah1989/EightZero/blob/master/src/keyboard.asm
Hehe, das haben wir alles in der Uni schonmal implementiert. Also die Softwareseite ist klar, aber die Links werde ich mir trotzdem nochmal angucken müssen. Ging mir eher darum, wo du den Anschluss her hast. Hab bei reichelt und Pollin nix in Richtung PS/2-Anschluss-buchse gefunden. Wäre halt ganz nett, die Tastatur vernünftig in eine Buchse stecken zu können.
Niklas Rpunkt schrieb: > Ging mir eher darum, wo du den Anschluss her hast. Hab bei reichelt und > Pollin nix in Richtung PS/2-Anschluss-buchse gefunden. Wäre halt ganz > nett, die Tastatur vernünftig in eine Buchse stecken zu können. Suche nach "mini din 6-polig". Da gibt es sowohl Printbuchsen als auch Kupplungen mit Kabel dran.
Nen µC mit externen Memory Controller bzw. Coprozessor Schnitstelle oder ne echte CPU mit Coprozessor Schnittstelle und nen FPGA. CPU am besten Von- Neumann-Architektur.
Ich habe noch ne Frage zum Gameduino. Zitat: The board needs two supplies. One is the 3.3V supply, the other is 3-5V to power the Gameduino’s LDO. This means that you can supply the Gameduino from a single 3.3V supply. Also auf logisch: Es braucht 2 Stromquellen, also folgt, es braucht eine stromquelle? Kann ich den 5V pin mit dem auf dem XPlained board verbinden oder muss ich mir ne extra Spannungsquelle suchen?
Niklas Rpunkt schrieb: > Also auf logisch: > Es braucht 2 Stromquellen, also folgt, es braucht eine stromquelle? > Kann ich den 5V pin mit dem auf dem XPlained board verbinden oder muss > ich mir ne extra Spannungsquelle suchen? Im Klartext: Du brauchst zwei Versorgungsspannungen. Die eine muss exakt 3.3V betragen, die andere kann irgendwas zwischen 3V und 5V sein. Folglich reicht auch einmal 3.3V, da 3.3 ja zwischen 3 und 5 liegt. Verstanden? Wichtig ist, dass du auf jeden fall einmal 3.3V brauchst (der Pin, an dem "+3.3V" steht). Den anderen Pin (wo "+5V" dran steht) kannst du dort mit anschließen, oder wenn vorhanden auch an 5V, das ist egal. Wo die Spannungen herkommen interessiert den Gameduino auch nicht wirklich. Nur sollte die 3.3V-Leitung stabil sein. Die andere Leitung ist nicht so kritisch, da sie intern sowieso reguliert wird, um die verschiedensten Spannungen für den FPGA zu erzeigen (2,2V oder was auch immer der noch so braucht).
Was spricht gegen VirtualBox oder qemu, also statt HW einen Emulator benutzten?
Stefan Noack schrieb: > Im Klartext: Du brauchst zwei Versorgungsspannungen. Die eine muss exakt > 3.3V betragen, die andere kann irgendwas zwischen 3V und 5V sein. > Folglich reicht auch einmal 3.3V, da 3.3 ja zwischen 3 und 5 liegt. > Verstanden? Wichtig ist, dass du auf jeden fall einmal 3.3V brauchst > (der Pin, an dem "+3.3V" steht). Den anderen Pin (wo "+5V" dran steht) > kannst du dort mit anschließen, oder wenn vorhanden auch an 5V, das ist > egal. Wo die Spannungen herkommen interessiert den Gameduino auch nicht > wirklich. Nur sollte die 3.3V-Leitung stabil sein. Die andere Leitung > ist nicht so kritisch, da sie intern sowieso reguliert wird, um die > verschiedensten Spannungen für den FPGA zu erzeigen (2,2V oder was auch > immer der noch so braucht). sprich: Ich brauche mir keine Gedanken machen, dass an dem ausgangspin genug strom durchfließt oder so? >Was spricht gegen VirtualBox oder qemu, also statt HW einen Emulator benutzten? Es handelt sich hierbei halt um spieleri und sowas hat einfach nich das gleiche Gefühl wie eine echte Maschine.
Niklas Rpunkt schrieb: > sprich: Ich brauche mir keine Gedanken machen, dass an dem ausgangspin > genug strom durchfließt oder so? Warte, ich mess mal nach, wieviel mA das Ding zieht... 120 bis 125 mA, ich denke mit 150 bist du auf der sicheren Seite. Warum eigentlich Ausgangspin? Die Spannungsversorgung kommt doch direkt vom Netzteil bzw. Spanungswandler. Ich habe übrigens gerade ein Video von meinem aktuellen Aufbau hochgeladen: http://www.youtube.com/watch?v=yZEEvJGjFTc
Also zuersteinmal ist dein Projekt ziemlich geil. Spielt von der Professionalität her aber weit außerhalb meiner Liga. Das Netzteilproblem: Der AVR32 Chip bekommt den Strom über den USB-Port. Bedeutet: Ich habe soweit erstmal kein extra Netzteil. Laut Spezifikation hat das Board einen 5V Ausgangspin der ziemlich stark sein soll (wie stark finde ich natürlich nirgendwo). Daran wollte ich den Gameduino anschließen.
Niklas Rpunkt schrieb: > Bedeutet: Ich habe soweit erstmal kein extra Netzteil. Laut > Spezifikation hat das Board einen 5V Ausgangspin der ziemlich stark sein > soll (wie stark finde ich natürlich nirgendwo). Daran wollte ich den > Gameduino anschließen. Das macht keinen Sinn. Nimm doch direkt die 5V vom USB. Für die 3.3V brauchst du allerdings sowieso einen Spannungswandler, der aus den 5V vom USB 3.3V macht.
Ist schon ziemlich spät und so aber wie komme ich an die 5 Volt vom USB für den Gameduino?
Niklas Rpunkt schrieb: > Ist schon ziemlich spät und so aber wie komme ich an die 5 Volt vom USB > für den Gameduino? Keine Ahnung, ist das nicht bei dem Board irgendwo nach außen geführt? Gibt's ein Foto von dem Board oder einen Schaltplan/Datenblatt?
Schau mal hier, Tabelle 3-2 auf Seite 6. http://www.mouser.com/ds/2/36/doc32159-49106.pdf Das ist doch das Board, das du nehmen willst, oder? An J1 hast du alles was du brauchst, um den Gameduino anzusteuern: SPI und sogar 3.3V Spannungsversorgung (5V brauchst du ja eigentlich nicht), einfacher geht's nun wirklich nicht. ;-)
Okay, sorry dass ich so schwer von Begriff bin^^ Dann schließe ich das so an PIN |Belegung ||Anschluss an |Bezeichnung ========+===============++=============+=========== GND |Signal ground ||J1-Pin09 |GND 3.3V |VCC ||J1-Pin10 |VCC_P3V3 11 |SPI MOSI ||PB10 |SPI1 MOSI 12 |SPI MISO ||PB08 |SPI1 MISO 13 |SPI SCK ||PB07 |SPI1 SCK 9 |SPI SEL ||PB09 |SPI1 CS0 und der Pin 5V Main supply: 3-6V hängt dann in der Luft?
Niklas Rpunkt schrieb im Beitrag # > und der Pin > 5V Main supply: 3-6V > hängt dann in der Luft? Nein, der kommt mit an VCC 3.3V Bei Pin 9 (Slave Select) musst du auch nochmal genau hinschauen. Der muss Low gezogen werden vor jedem SPI-Datentransfer und danach wieder High. Ich musste dafür einen GPIO-Pin nehmen, da bei meinem Mikrocontroller "SPI CS" bei aktiviertem SPI ein Eingang ist, der ihn als Slave auswählt. Im Master-betrieb muss der natürlich immer High sein. Am besten du schaust mal ins Datenblatt von deinem Mikrocontroller, da sollte das genau drinstehen, wie man ein Gerät über SPI anschließt.
Okay ich glaube ich habs jetzt verstanden, aber um sicher zu gehen und damit ich nachher nicht aus schusseligkeit das board frittiere, wiederhole ich nochmal: Alles wie oben nur 5V Main supply: 3-6V und VCC werden beide gemeinsam an den selben Pin angeschlossen. Wie SPI funktioniert finde ich mit dem Datenblatt bestimmt raus, danke dafür =)
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.