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.
@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.
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.
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).
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.
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 =)
