Druckbare Version
SPI, hmmm, das klingt auch interessant. Hatte ich mich noch nie mit auseinandergesetzt (außer beim programmieren...... :-D)
Scheint sich sehr einfach implementieren zu lassen in BASCOM, da werde ich einfach mal RN-Control und Tricopter zusammenhängen, Bytes hin und herschicken und die Frequenz meiner Regelung messen... Oder gibt es hier Erfahrungswerte? Wie sieht das hier aus mit Interrupts/ Timern etc?
Hi,
ich habe jetzt mal eine SPI Kommunikation zwischen zwei Mega32 aufgebaut. Allerdings bin ich nicht ganz zufrieden: Mein Master überträgt 4 bytes zum Slave. Nur scheint dadurch der Slave total ausgelastet zu sein. Das liegt wohl daran dass ich ein "on SPI" interrupt verwende, aber wie komme ich ohne den aus..?
Hier der Code vom Master:
Der code vom Slave:Code:'MASTER
'===CHIP SETTINGS===
$regfile = "m32def.dat"
$framesize = 32
$swstack = 32
$hwstack = 32
$crystal = 16000000
$baud = 19200
'SPI
Config Spi = Hard , Interrupt = Off , Data Order = Lsb , Master = Yes , Polarity = High , Phase = 1 , Clockrate = 4
'SPI
Dim A(4) As Byte
Enable Interrupts
Spiinit
'Main Loop soll nur die 4 Bytes verändern
Do
If A(1) < 200 Then
Incr A(1)
Else
A(1) = 16
End If
If A(2) < 250 Then
Incr A(2)
Else
A(2) = 0
End If
If A(3) > 1 Then
Decr A(3)
Else
A(3) = 233
End If
If A(4) > 60 Then
Decr A(4)
Else
A(4) = 160
End If
Spiout A(1) , 4
Waitms 3 '300Hz transfer von 4 bytes ist das ziel
Loop
Alle Leitungen (MOSI, MISO, SCK, SS) sind direkt 1:1 verbunden. Hatte es zwar erst aus "Sicherheitsgründen" mit 10k Widerständen versucht aber da ging gar nix.Code:'===CHIP SETTINGS===
$regfile = "m32def.dat"
$framesize = 32
$swstack = 32
$hwstack = 32
$crystal = 16000000
$baud = 19200
'SPI
Config Spi = Hard , Interrupt = On , Data Order = Lsb , Master = No , Polarity = High , Phase = 1 , Clockrate = 4
Dim A(4) As Byte
Enable Interrupts
On Spi Wasempfangen
Enable Spi
Spiinit
Do
Toggle Led_gelb
Waitms 3 'wenn die led regelmäßig hell ist -> µC läuft ungestört. Ist aber nicht so
Loop
'SPI
Wasempfangen:
Spiin A(1) , 4
Toggle Led_rot 'diese flackert auch sehr unregelmäßig
Return
Hat jemand einen Tipp wie ich ohne Interrupts auskomme? Ich dachte mein Haupt-µC soll der Slave sein, da er dann kein SCK erzeugen muss. Ist das sinnvoll? Wie könnte überhaupt ein Master Daten vom Slave empfangen?
Was auch ein bisschen nervt: Zum programmieren (über die ISP Schnittstelle) muss ich jedes mal die SPI Verbindung Master/Slave trennen, sonst werden die µC's nicht erkannt. Gibts da vielleicht nen Trick?
Vielen Dank für eure Hilfe!
Hallo.
Ich kenne mich mit Bascom überhaupt nicht aus, aber nach der Dokumentation hast Du eine SPI Clock von 16Mhz/4=4MHz. Dies kommt mir sehr hoch (Störeinflüsse usw.), vielleicht versuchts Du mal den Teiler 128, dies sollte nach Atmega Doku auch gehen. Mal sehen wie sich dann die LEDs verhalten.
Gruss
Volly
Hi,
auch ich kenne mich mit Bascom nicht aus, aber ich habe schon öfter 2 Megas per TWI verbunden. Der Master holt sich bei mir die Daten, wenn er sie braucht und Zeit hat :D
Der Slave liest Sensoren, berechnet und legt die Ergebnisse in einem Puffer ab, auf den der Master freien Lese/Schreibzugriff hat.
In einer anderen Schaltung habe ich ein Display (DOG-M132 und 128) mit einem Mega32 bzw Mega644 ausgestattet und dem die ganze Verwaltung/das Zeichnen überlassen. Die Masterschaltung steuert über TWI das Display. Allerdings schickt der Master nur z.b. $11,$00,$00,$7F,$3F,$FF und der Slave zeichnet ein Rechteck (Befehl $11) mit den Eckkoordinaten 0,0,127,63. das $FF am Ende ist das Musterbyte der Umrandung. Ich habe die Datensatzlänge auf 16 Bytes Nutzdaten festgelegt. maximal möglich wären 64k !. Zu den Nutzdaten kommen bei mir noch Start/Stop und eine Prüfsumme. Das macht aber alles mein Compiler bzw. die Library ;)
gruss
Harry
Hallo Harry,
dies klingt sehr interessant:
Aber was verstehst Du unter einem Puffer (Dual Port Ram?)?Zitat:
Der Slave liest Sensoren, berechnet und legt die Ergebnisse in einem Puffer ab, auf den der Master freien Lese/Schreibzugriff hat.
Gruss
Volly
@Crazy Harry:
Im moment probiere ich noch SPI aus, aber vielleicht ist TWI doch besser geeignet?!?
So, ich habe mal fleißig weiter mit SPI rumprobiert. Auch wenn ich den Teiler auf 128 setze - sobald ich den SPI Interrupt benutze zerhauts mir den Rest meiner Ansteuerung (Servos zucken dann rum etc).
Ich habs jetzt auch mal ohne Interrupt versucht. In diesem Fall wartet der µC dann einfach so lange bis über SPI was reinkommt. Falls nichts kommt wartet er eben ewig und blockiert meine Regelung total. Das ist das gleiche wie der Bascom Befehl "INPUT" bei dem ewig auf Daten per RS232 gewartet wird.
Jetzt komm ich nicht so richtig weiter....
Ich glaub so etwas bräuchte ich auch. Und falls der Master mal nichts abholen sollte, dann sollten die Daten im Puffer vom Slave einfach ersetzt werden...Zitat:
Der Slave liest Sensoren, berechnet und legt die Ergebnisse in einem Puffer ab, auf den der Master freien Lese/Schreibzugriff hat.
das ist etwas kompliziert zu erklären. ich programmiere nicht mit bascom, c oder assembler, sondern mit pascal (avrco) und dort gibt es eine unit für twinet. ich definiere im slave einen puffer (z.b. 16 byte) der im programm dann TWIrxBuff[] und TWItxBuff[] heißt und auf diese variablen hat sowohl der master als auch der slave zugriff.Zitat:
Zitat von Volly42
aber im endeffekt ist das nichts anderes als RAM im slave.
@Harry
Die Idee mit dem Array im Slave ist eine gute Lösung, so bräuchte man keinen Interrupt mehr im Master, sondern der würde sich die Daten einfach dann abholen, wenn er sie braucht. Das Schreiben vom Slave in sein eigenes würde dann zyklisch mit einem Timer erfolgen.
Hardwaretechnisch wäre dies auch mit einem zusätzlichen SRAM mit SPI Schnittstelle lösbar:
http://ww1.microchip.com/downloads/e...Doc/22100C.pdf
Das Problem beim Teil ist nur, daß die Spannungen mit 3,3 V laufen, ob hier einfach Spannungsteiler einsetzbar sind, kann ich nicht beurteilen.
Gruss
Volly
Ja da hat Joe wohl wieder recht... Nach gescheiterten Versuchen mit SPI habe ich es doch noch mal mit dieser "so unprofessionell nach Terminal klingenden Schnittstelle" versucht. Und siehe da: Perfekt! Sauschnell, eigentlich unkompliziert und auf die Bedürfnisse anpassbar.Zitat:
Tatsächlich funktioniert hatte bei mir die Kommunikation zwischen zwei Controllern mit dem seriellen Protokoll "TTL"232. Lief bisher in der Testphase zufriedenstellend und fehlerfrei mit 57600 Bd. Ich hatte es noch nie in der eigentlichen Funktionsumgebung realisiert, da ich mir den zweiten Controller bisher gespart hatte. Das scheint mir als Kommunikation zwischen zwei Kontrollern sinnvoll und ausreichend schnell zu sein - und die Hardware ist ja bei megas praktisch immer vorhanden.
Ich werde drei Bytes (zusätzliche Motor-Sollwerte) von einem Mega8 auf nen Mega32 übertragen. Ohne Übertragung läuft die Regelung mit 359Hz, wenn ich mit 200Hz Daten übertrage läufts noch mit 347 Hz. Also wirklich perfekt für meine Zwecke. Die Sensorwerte können im Mega8 komplett vorverdaut werden, das entlastet den Haupt µC zusätzlich.
Das Problem scheint ja gelöst zu sei, aber man könnte versuchen weiter mit einer µC auszukommen. Mit dem Mega644 hätte man mehr Speicher und wenn man statt BASCOM die Programmierung in C macht, sollten besonders die Interruptzeiten deutlich schneller werden. Auch sonst ist der Code vermutlich etwas kürzer und schneller.
Wenn man nur 2 µCs koppelt hat die UART tatsächlich ein paar Vorteile, weil es halt kein Bus ist und das Protokoll einfacher ist. An sich sollte aber auch TWI oder SPI gehen ohne das alles andere zu stark ausgebremst wird. Das könnte an den vordefinierten Routinen von BASIC liegen.