|
Anzeige
|
16-Bit SPI Slave mit AVR
Gast
#707165
Hallo, ich benötige einen µC der als SPI Slave fungieren soll. Hierbei wird vom SPI Master eine 16-Bit Übertragung bei einem SPI-Takt von 1Mhz genutzt. Gibt es eine Möglichkeit, hierfür ein µC der AVR Serie einzusetzen? Laut Datenblatt unterstützt dieser ja nur 8-Bit Übertragung. Richtig? Gruß
Gast
#707187
Ja, dann muss man eben 2 byte hintereinander schieben. SPI mit 1MHz sollte gehen. Der Clock muesste dann mind 8MHz sein.
Gast
#707201
Ich frage mich ob der AVR das handeln kann, wenn 16-Bit daten am Stück mit 1 MHz ankommen. Interessant wäre auch was passiert wenn ich 8-Bit auslese und zu diesem Zeitpunkt schon die nächsten 8-Bit ankommen. Genauso ist die Frage, ob ich 16-Bit Daten am Stück (mit 1MHz) zurück zum Master schicken kann.
Gast
#707226
1 MHz SPI ist nun nicht soooviel. Da der Empfang 2fach gepuffert ist, kann man die ersten 8Bit auslesen (sobald die ersten 8Bits empfangen, werden die automatisch in ein "Schattenregister" transferiert), derweil die nächsten Bits eintrudeln. Steht sehr gut im Datenblatt beschrieben.
Gast
#707245
Danke für die Antwort, du hast natürlich rest. Der Empfangspuffer ist doppelt ausgeführt und somit habe ich ~8 SPI CLocks Zeit das Empfangspuffer auszulesen. Doch der Sendepuffer ist nur einfach ausgeführt: "The system is single buffered in the transmit direction and double buffered in the receive direction. This means that bytes to be transmitted cannot be written to the SPI Data Register before the entire shift cycle is completed." D.h. das ich innerhalb eines SPI Takts das Senderegister neu beschreiben muss (nach ende der ersten 8-Bit und vor dem ersten neuen Bit der zweiten 8-Bit). Und ich denk daran würde es dann wohl scheitern. Da ich den internen Oszilator verwenden möchte (8MHz) wird das wohl nicht zeitlich reichen :( Der Sender gibt doch auch den Takt vor. Wenn also das Senderegister geleert wurde, wird der Takt angehalten, und man kann den Sendepuffer neu füllen. Dann startet man eine neue Übertragung. Der zitierte Satz bedeutet nur, dass das Senden etwas "unkomfortabler" als der Empfang ist. Rahul Der trollige wrote: > Der Sender gibt doch auch den Takt vor. Nein, der Master gibt den Takt aus. Gesendet und empfangen wird immer gleichzeitig. Und wenn der Slave bei 1MHz was senden soll, hat er max 1µs Zeit, das Senderegister zu befüllen. Sieht also sehr schlecht aus für den AVR als Slave. Man könnte nen AT89LP4052 nehmen, der hat auch nen Sendepuffer. Peter
Gast
#707285
Danke für die Antwort, das dachte ich mir schon fast :( Ich benötige ein µC mit: -internem Oszilator -5V Versorgung -SPI Slave fähig bei 1MHz und 16-Bit Datenübertragung -Minimalbeschaltung (nur Versorgung, Stützkondensatoren und Pull-up am Reset nötig) -Flash (~1k reicht) -freier C-Compiler und günstigem Programmierer -max. 32 Pins in SMD (TQFP oder was ähnliches, nur kein BGA) Ansonsten brauch ich nichts an Peripherie. Lediglich ne handvoll digitale IOs. Vielleicht hat jemand eine Idee? @ AVR-User (Gast) >Ich benötige ein µC mit: >-internem Oszilator >-5V Versorgung >-SPI Slave fähig bei 1MHz und 16-Bit Datenübertragung >-Minimalbeschaltung (nur Versorgung, Stützkondensatoren und Pull-up am >Reset nötig) >-Flash (~1k reicht) >-freier C-Compiler und günstigem Programmierer >-max. 32 Pins in SMD (TQFP oder was ähnliches, nur kein BGA) Kann alles der AVR wenn er als Slave nicht senden muss. Was soll der den machen? Vielleicht geht ja auch ein CPLD? MFg Falk
Gast
#707313
Ja genau deshalb dachte ich ja zunächst an einen AVR. Der µC soll zwei 16-Bit Pakete einlesen. Diese werden mehrfach verschickt. Wenn x mal die gleichen Pakete empfangen -> Daten weiterreichen an Schieberegister. Außerdem soll ein weiteres Schieberegister und digitale IOs eingelesen werden und auf den SPI-Bus gelegt werden. Das "Protokoll" ist leider fest. Dabei soll der Entwicklungsaufwand aufs minimale beschränkt werden. @ AVR-User (Gast) >weiterreichen an Schieberegister. Außerdem soll ein weiteres >Schieberegister und digitale IOs eingelesen werden und auf den SPI-Bus >gelegt werden. Das "Protokoll" ist leider fest. Klingt nach einem IO-Expander mit SPI Anschluss. Sowas ist besser mit einem CPLD gemacht. 72 Macrozellen sollten reichen. MFG Falk
Gast
#707321
Gut möglich, dass ein CPLD dafür geeignet ist. Nur wie siehts da mit Einarbeitungszeit, Entwicklungszeit, Bauteilkosten und Kosten für Entwicklungstools aus? Habe bisher keine Erfahrung mit CPLDs, FPGAs und Co. @ AVR-User (Gast) >Gut möglich, dass ein CPLD dafür geeignet ist. Nur wie siehts da mit >Einarbeitungszeit, Entwicklungszeit, Bauteilkosten und Kosten für >Entwicklungstools aus? Habe bisher keine Erfahrung mit CPLDs, FPGAs und >Co. Von nix ist nix. Die Einarbeitungszeit ist je nach Hintergrund zwischen zwei Wochen bis zwei Monaten, ggf. mehr. Entwicklungszeit ist, so man in der Materie drin steckt, eher kurz, ich würde mal auf 3 Tage tippen, eher weniger. Bauteilkosten sind abhängig vom Lieferanten und Abnahmemenge, der XC9572XL kostet bei Angelika R. aus S. im PC44 Gehäuse 2,90 (jaja, Ziegelstein). Bei http://www.nuhorizons.com bekommt man den für $2,12. MFG Falk Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
