hi.
irgendwie komme ich nicht weiter. ich scripte mit lunaavr und habe zwei
atmega32. beide sollen miteinander ueber spi komunizieren.
der master wird innerhalb der loop-schleife mit
1
spislave1=0
2
spi.master.writebyte(wert1)
3
spislave1=1
gefuettert und der slave faengt das ebenfalls in der loop mit
1
wert=spi.slave.readbyte
ab.
so weit funktioniert das. aber ich moechte mehr als nur ein byte
uebertragen.
master:
1
spislave1=0
2
spi.master.writebyte(wert1)
3
spi.master.writebyte(wert2)
4
spislave1=1
slave:
1
wert=spi.slave.readbyte
2
wert2=spi.slave.readbyte
funktioniert nicht.
kann mir da jemand helfen?
gruß
tom
ich würde meinen das zweite byte wird nicht zwangsläufig beim pollen
auch mit dem richtigen Timing ausgelesen. wenn es mit einem delay
funktioniert, dann wird das wohl so sein.
nimm zum Empfang doch die ISR und pack die bytes in einen buffer.
Mike schrieb:> nimm zum Empfang doch die ISR und pack die bytes in einen buffer.
hm ... hast du dafuer ein beispiel? mir ist es nicht ganz so gelaeufig
tom
tom schrieb:> irgendwie komme ich nicht weiter. ich scripte mit lunaavr und habe zwei> atmega32. beide sollen miteinander ueber spi komunizieren.
Du weißt, dass das Codieren der letzte Schritt einer Entwicklung ist?
Anus Praeter schrieb:> Du weißt, dass das Codieren der letzte Schritt einer Entwicklung ist?
ja. aber irgendwie muss man erst einmal das entwickeln lernen damit man
was entwickeln kann. das weisst du?
ich lerne auf dem praktischem autodidaktischem weg. darum frage ich wie
ein noob nach unterstuetzung und nicht wie ein profi.
Tom,
warum wendest Du Dich nicht an das hauseigene Forum von LunaAVR?
Die Leute dort müssten Dir doch am besten sagen können, wie deren
Software und Libraries und hast Du nicht gesehen funktionieren
soll(t)en.
Stelle einfach dort die Frage. Mache eine Weltreise und wenn Du wieder
kommst hast Du vielleicht die passende Lösung.
So schön die IDE von Luna auch sein sollte, aber die Libs mit der
mangelhaften Dokumentation und dem fragwürdigen Support stellen trotz
der angeblichen "anfängerfreundlichen" Umgebung eher was für Profis dar,
die sonst keine Fragen haben.
Die Tatsache, das dort Fragen mit weniger hilfreichen, meist mehr oder
weniger inhaltlosen Gegenfragen beantwortet werden, sollte einem schon
zu denken geben.
Have fun
Fusel
Der Master kann zwar senden, wann er will, der Slave aber nicht
empfangen, wann er will.
Der Slave muß exakt in dem Augenblick das Datenregister auslesen, wenn
der Master das Byte gesendet hat. Nicht früher oder später, sondern
genau dann. Und das geht eigentlich nur mit Interrupt.
Fusel schrieb:> aber die Libs mit der> mangelhaften Dokumentation und dem fragwürdigen Support stellen trotz> der angeblichen "anfängerfreundlichen" Umgebung eher was für Profis dar,> die sonst keine Fragen haben.
also ich sehe mich definitiv nicht als Profi, ich finde die
Dokumentation durchaus sehr detailliert, da steht auch nicht mehr oder
weniger drin als was man erwartet. 1. ne Kurzbeschreibung, die
Funktionen und in 90% der Fälle ein Code-Beispiel. Das man nicht allen
alles servierfertig vorkauen kann ist klar, ich musste da auch lernen.
Moin Harald,
harald schrieb:> Das man nicht allen> alles servierfertig vorkauen kann ist klar, ich musste da auch lernen.
da gebe ich Dir vollkommen recht. Ich persönlich fände es auch ziemlich
langweilig wenn dem so wäre. Ich bastel lieber selber herum und freue
mich anschließend wenn etwas passiert/funktioniert.
harald schrieb:> ich finde die> Dokumentation durchaus sehr detailliert, da steht auch nicht mehr oder> weniger drin als was man erwartet. 1. ne Kurzbeschreibung, die> Funktionen und in 90% der Fälle ein Code-Beispiel
Echt? Hast Du eine andere Dokumentation als wie ich?
Ich sehe zumindest in der PDF-Variante nur designbedingt abgeschnittene
Infos die ja (aus welchen Gründen auch immer) in einem
Inline-Frame-Design eingefügt werden müssen.
Ja Grundfunktionen und Methoden werden aufgeführt. Aber nicht welche
benötigt werden und wie sie funktionieren. Für einen Anfänger ist das
nichts obwohl man dort in den FAQ ja schreibt "anfängerfreundlich".
Ich verfolge gerade bei denen im Forum mit, wie der TE dort um Hilfe
betteln muss. Der Autor der Lib antwortet ja fleissig ... mit
Gegenfragen!
Entschuldige, aber fachlich kompetente und aussagekräftige Hilfe sieht
für mich definitiv anders aus. Entweder ist der Autor selber Ahnungslos
oder verfused. :D
@tom:
Ich muß dem Uwe aber recht geben: Nehme I2C/TWI für Deine Zwecke.
Benutze die beiden Master- und Slave-Libs im Example-Ordner und fuchse
Dich dort ein wenig rein. Die Dinger funktionieren schon irgendwie.
Eigentlich ganz einfach sogar. Bin auch ein Anfänger und hatte nach ca.
10 Minuten den Durchblick. ;-)
Gruß
Fusel
Fusel schrieb:> Nehme I2C/TWI für Deine Zwecke.
Das AVR-SPI ist eh nicht tauglich für MC-MC Kommunikation. Stätestens
beim Slave-Transmitter kracht es.
Das I2C hat dagegen ein Handhake eingebaut. Der Master wartet immer auf
den Slave, bis der SCL wieder auf high zieht, d.h. sein Byte gelesen
oder geschrieben hat.
Fusel schrieb:> Echt? Hast Du eine andere Dokumentation als wie ich?> Ich sehe zumindest in der PDF-Variante nur designbedingt abgeschnittene> Infos die ja (aus welchen Gründen auch immer) in einem> Inline-Frame-Design eingefügt werden müssen.> Ja Grundfunktionen und Methoden werden aufgeführt. Aber nicht welche> benötigt werden und wie sie funktionieren. Für einen Anfänger ist das> nichts obwohl man dort in den FAQ ja schreibt "anfängerfreundlich".
hmm, ich benutze die Online-Dokumentation und wenn man bezüglich dem TWI
die entsprechende Seite aufruft, erscheint bei mir eine Beschreibung,
ein Verschaltungsbild, die Liste der Funktionen und ein komplett
funktionierendes Master-Beispiel. Die ganzen Beispiele sind ja im Ordner
Examples auch vorhanden, inkl. ein funktionierendes Slave-Beispiel!
Das ist doch nichts anderes als wie hier, das ist ein Wiki, wenn es
jemand verstanden hat kann er es ja erweitern. Sorry, aber bissl selber
nachdenken muss man schon, schau doch mal was hier passiert wenn einer
nen Problem hat und nur mit halben Infos rausrückt was er eigentlich
machen will.
Wenn ich ein Problem habe, dann beschreibe ich das möglichst komplett,
kann ja sein das ich auf dem Holzweg bin mit meiner Idee und so ist es
ja scheinbar auch wenn man mit SPI ein Haus vernetzen wollte.
Peter Dannegger schrieb:> Das AVR-SPI ist eh nicht tauglich für MC-MC Kommunikation. Stätestens> beim Slave-Transmitter kracht es.
Na ein Glück, daß meine AVRs von dieser neuesten Danneggerschen
Horrorstory noch nix gehört haben...
Sonst könnte ich z.B. nicht mit dem Teil hier
> http://nanorivertech.com/nanoboard.html
kommunizieren, denn das kann nur SPI-Master. Ich kann aber mit dem Ding
reden, was wohl bedeuten muß, daß mein AVR Slave ist, was mich
allerdings nicht überrascht, denn ich habe ihn tatsächlich auch als
solchen programmiert.
Übrigens: Das, was NanoRiverTech da auf den Drawings als
"USB-Controller" apostrophiert, ist nix anderes als ein PIC, womit wohl
das Szenario einer MC-MC-Kommunikation als gegeben anzusehen wäre...
Fazit: Wer wirklich programmieren kann, kriegt auch einen AVR als
SPI-Slave zum Laufen. Eigentlich ist das sogar überhaupt kein Problem,
wenn man die Interrupt-Latenzen seiner Anwendung unter Kontrolle hat und
keine angesichts dieser Latenzen unrealistisch hohe Bitrate für die
SPI-Kommunikation wählt. Es muß einfach nur gewährleistet werden, daß
auch im worst case innerhalb von 7,5 SPI-Takten nach dem IRQ das zu
sendende Byte in SPIDR angekommen ist, dann flutscht SPI auch im
Slave-Mode problemlos.
Im konkreten Fall wird übrigens 750kHz SPI-Takt verwendet. Naja, nicht
gerade berauschend, aber ausreichend für das Problem und mit nur
minimalen Umbauten der bestehenden Anwendung zu erreichen.
Es ging konkret darum, die Ergebnisse einer Signalverarbeitung in der
AVR-Anwendung zu Debugging-Zwecken in Echtzeit in einen PC zu kriegen.
Der naheliegende Weg, daß einfach via UART zu erledigen, schied leider
wegen ungünstiger Taktfrequenz des AVR-Systems aus. Eine Änderung von
20MHz auf 18.432MHz wäre zwar performancemäßig möglich gewesen, hätte
aber erheblich mehr Änderungen an der Anwendung nach sich gezogen als
der Einbau der Ausgabe via SPI-Slave. Insbesondere wären tiefgreifende
Änderungen am zu debuggenden Teil der Anwendung selber nötig geworden,
was das Debugging einigermaßen nutzlos hätte werden lassen.
c-hater schrieb:> Es muß einfach nur gewährleistet werden, daß> auch im worst case innerhalb von 7,5 SPI-Takten nach dem IRQ das zu> sendende Byte in SPIDR angekommen ist, dann flutscht SPI auch im> Slave-Mode problemlos.
Nö, Du hast als Slave nur 0,5 SPI-Takte Zeit, das Byte ins
Schieberegister zu schreiben, da das SPI keinen Sendepuffer hat, nur
einen Empfangspuffer.
Natürlich kann man das Slave-Senden auf dem AVR irgendwie zusammen
schustern, nur muß dann der Master lange Gedenkpausen einlegen oder den
Takt deutlich verlangsamen. Und das ist definitiv nicht das, was ich
unter einem brauchbaren SPI verstehe.
Slave SPI ist daher auf dem AVR alles andere als trivial und erst recht
nicht Anfänger tauglich.
Z.B. beim AT89LP4052 hat Atmel nicht so einen Mist gebaut, der hat ein
"Enhanced SPI with Double-buffered Send/Receive". Das ist aber kein AVR,
sondern ein 8051.
Damit kann man bequem den maximalen Takt F_CPU/4 = 5MHz nehmen, ohne
Datenbrei befürchten zu müssen.
Peter Dannegger schrieb:> Nö, Du hast als Slave nur 0,5 SPI-Takte Zeit, das Byte ins> Schieberegister zu schreiben
Ja, richtig, das hatte ich glatt vergessen (ist schon eine kleine Weile
her).
Man hat bei kontinuierlichem Takt wirklich nur 0,5 SPI-Takte Zeit, das
stimmt. Dazu kommt allerdings die Zeit, die der Master einem gibt. Im
konkreten Fall summierte sich das ziemlich genau zu 7,5 SPI-Takten.
> Natürlich kann man das Slave-Senden auf dem AVR irgendwie zusammen> schustern, nur muß dann der Master lange Gedenkpausen einlegen
Das ist genau das Szenario.
Der Punkt ist: Der PIC auf dem Nanoboard hat wohl genauso zu kämpfen,
denn der muß ja noch nebenbei USB fullspeed in Echtzeit bedienen und
legt deshalb die "Gedenkpausen" wohl mehr oder weniger "freiwillig" ein.
Dokumentiert sind sie beim Nanoboard übrigens nicht, ich mußte sie
damals erst beim Support erfragen.
However: Es ist eine funktionierende MC-MC-Kommunikation via SPI mit dem
AVR als Slave. Und sie ist durchaus brauchbar, ich habe damit jedenfalls
letztlich den Fehler in der Signalverarbeitung gefunden. :o)
Davon mal abgesehen: Eine echte Dauerstrich-Kommunikation mit
kontinuierlichem Takt kriegt AVR-SPI ja nichtmal als Master hin, selbst
wenn er garnix anderes zu tun hat, das geht nur mit USART im SPI-Mode.
c-hater schrieb:>> Der Punkt ist: Der PIC auf dem Nanoboard hat wohl genauso zu kämpfen,> denn der muß ja noch nebenbei USB fullspeed in Echtzeit bedienen und> legt deshalb die "Gedenkpausen" wohl mehr oder weniger "freiwillig" ein.> Dokumentiert sind sie beim Nanoboard übrigens nicht, ich mußte sie> damals erst beim Support erfragen.>
Dann haben die den falschen PIC verwendet ;)
Ich bastle gerade mit einem PIC24FJ128GC010, der hat 8fach Read/Write
SPI Fifo und das lässt sich über DMA füllen bzw. leeren. Full Speed USB
macht parallel die CPU oder über andere DMA Kanäle.
Hans-Georg Lehnard schrieb:> Dann haben die den falschen PIC verwendet ;)
Ich habe vergessen, welcher das genau ist, kann aber morgen (oops, ist
ja schon morgen, also heute) oder spätestens am Montag diese Information
nachliefern. Aber irgendwas mit PIC24... war es, da bin ich ziemlich
sicher.
Die eDIP von Electronic Assembly haben ja auch einen AVR:
"Das eDIP benötigt eine bestimmte Zeit um die Daten
bereit zu stellen; deshalb muss vor jedem zu lesenden
Byte mindestens 6μs gewartet werden (keine Aktivität
auf der CLK Leitung)."
Das tut schon richtig dolle weh, wenn man im SPI-Interrupt 120 CPU
Zyklen nutzlos verwarten muß.
Thread beobachten
Seitenaufteilung abschalten