Hallo zusammen! Ich habe ein kleines Problem in Bascom und zwar mit dem SHIFTOUT- Befehl. Mithilfe der Themensuche hier im Forum konnte ich nichts finden, was in Bascom geschrieben war, oder mein Problem beschreibt, desswegen hier ein neuer Eintrag. Mein Ziel ist es von einem ATtiny13 zu einem ATmega8 einen Bytestrom zu senden. Dieser Bytestrom soll dann beim ATmega8 mithilfe der SHIFTIN- Funktion als Variable gespeichert werden und aufgrund dieser dann die entsprechende Sub- Routine aufrufen. Aus der Hilfestellung von Bacom bin ich nicht wirklich schlau geworden und auch sonst habe ich im netz nichts gefunden was mir weiterhalf, desswegen frage ich jetzt euch, ob ihr mir helfen könnt. Im Anhang habe ich mal ein Versuchscode reingepackt. Was ich nicht ganz verstehe ist, in der Hilfestellung steht, dass ich bei diesem Befehl mit der Variable 4 irgendwo an 4. Stelle nach "SHIFTOUT" einen externen Takt verwenden kann, bzw. das habe ich gemacht mit der PWM- FUnktion, was anber dann auch nicht funktionierte :-( Ich hoffe ihr habt eine Idee. (Sorry, der Code ist etwas unübersichtlich, und am einen Pin, der getogglet wird ist eine Kontroll- Led angebacht) Freundliche Grüsse Andi
Als Clock ist ein Port-Pin gemeint. Im Prinzip läuft Shiftout so ab: Es wird das gewünschte Hi/Lo Signal an PIN angelegt. Ist dieses stabil, wird Clock kurz getoggelt, dann das nächste Bit an PIN angelegt und wieder getoggelt usw. Steht auch alles in der Hilfe. Das Beispiel dazu findet sich unter SHIFTIN. Bascom 2.0.6.2 und 2.0.6.3 haben ein Bit Problem. Also sicherstellen, dass du die neueste Version 2.0.7.0 nutzt(oder eine ältere als die gennanten)
Also zuerst mal, bezieht sich dieses Bit Problem auch auf die Demo Version? Ich arbeite mit dieser Version von Bascom. Was meinst du genau mit dem gewünschten Hi/ Lo Signal? Ich habe den Eindruck dass du da gerade Shiftin beschreibst, da es dabei um das Einlesen geht. Ich habe allerdings Probleme mit dem Auslesen.
Andi K. schrieb: > Mein Ziel ist es von einem ATtiny13 zu einem ATmega8 einen Bytestrom zu > senden. Das geht so nicht. SHIFTOUT und SHIFTIN sind SW-SPI-Master. Peter
Hallo Andi, ich denke der Fehler liegt am Clock. beim Shiftout erzeugst du die zu den Daten gehörige Clock....und toggelst damit den Pin. Du hast ihn jedoch als Eingang deklariert. Gruß BoGe-Ro
@Bodo - So, ich habe das Programm geändert und es tat sich noch immer nichts. Ich denke dass das an der Sache liegt, die Peter erwähnt hat. @Peter - was bedeutet das genau? bzw, gibt es eine andere Möglichkeit eine Kommunikation dieser art herzustellen? Evt. mit I2C oder so? Gruss Andi
Peter Dannegger schrieb: > Das geht so nicht. SHIFTOUT und SHIFTIN sind SW-SPI-Master. Das ist nicht richtig. Mit Parameter +4 wird externer Clock akzeptiert.
1 | Shiftin Ser_In , Clock_In , B , 4 , 8 |
Nachtrag: Da Beschreibung und Funktion von Shiftin mit ext. Clock abweicht, dürfte Folgendes zusammenpassen: Sender:
1 | Clock_Out Alias PortX.0 |
2 | Ser_Out Alias PortX.1 |
3 | Shiftout Ser_Out , Clock_Out , B , 0 |
Empfänger:
1 | Clock_In Alias PinX.0 |
2 | Ser_In Alias PinX.1 |
3 | Shiftin Ser_In , Clock_In , B , 5 ' <-- samples at falling ext clock |
Angehängte Dateien:
-
_MAP001.png
2,6 KB
Ok, ich habe mal das Programm von MWS nachgeschrieben und ausprobiert. Ich bin mir nicht sicher ob das nur geht wenn zum Sender auch ein Empfänger vorhanden ist, ich habe es einfach mal mit dem Oszilloskop gemessen und da hat sich nicht viel getan. Im Anhang habe ich das aktuelle Programm und dazu noch ein Screenshot vom Oszi. Darauf ist zu sehen dass ich vor dem Shiftout eine stegende Flanke habe, die 100ms lang ist, dannach sieht man die gelbe Flanke, welche zumindest einen Teil des Shiftout Befehls ist und gleich 100ms später wie die blaue Flanke wieder abfällt. Ich wollte somit schauen was diese eine Zeile macht und habe sie desswegen so "begrentz". Was meint ihr nun dazu?
Andi K. schrieb: > Ich bin mir nicht sicher ob das nur geht wenn zum Sender auch ein > Empfänger vorhanden ist, Da gibt's keine weitere "Eigenintelligenz", es werden einfach nur die Bits rausgetaktet und dazu der Clock erzeugt. Wüsste auch nicht, was Du mit 'nem Raster von 200ms sehen willst, wenn das Rausschieben knapp 17µs dauert. Da kannst Du auf dem Oszi noch gar nichts erkennen. Mit dem Parameter "delay" lässt sich die Sache verlangsamen.
Achso gut, das war auch eine Frage die ich mir gestellt habe, wie lange dieser Prozes dauert. dn werde ich heute Abend mir dasnochmal anschauen. Aber wieso ist der Ausgag nach dem Vorgang auf High und nicht auf Low? Andi
Andi K. schrieb: > Aber wieso ist der Ausgag nach dem Vorgang auf High und nicht auf Low? Wenn Shiftout() mit Option 0 = "MSB shifted out first when clock goes low" konfiguriert ist, wie sollte es denn sonst den ersten Takt ausgeben, wenn Clock vorher nicht High ist ? Die .cfg musst Du im Übrigen nicht mitposten.
Heisst das aso, dass das was ich auf dem Oszi habe nur der erste Takt ist? und kann ich irgendwo diese Clock an einem Pin abgreifen damit ich überhaupt mal sehen kann wie das Ganze taktet? ich finde die Beschreibung dazu in des Bascom- Hilfe zimlich mager.
Andi K. schrieb: > Heisst das aso, dass das was ich auf dem Oszi habe nur der erste Takt > ist? Ob erster oder letzter Takt is egal, Du kannst nichts davon erkennen, da 200ms/div viel zu lang ist. Setzt das Shiftout() in 'ne Do/Loop, mach' meinetwegen noch ein Waitms dazu, laß den anderen sbi/cbi Kram weg. Laß laufen und triggere auf fallende Flanke. Div sollte um die 2-5µs eingestellt sein. Andi K. schrieb: > ich finde die > Beschreibung dazu in des Bascom- Hilfe zimlich mager. Die ist mehr als ausreichend. Das Prinzip erklärt sie nicht, sollte man aber schon selbst wissen, und sonst steht alles da, z.B.: "When the clock is too fast you can specify a delay time(in uS)."
Angehängte Dateien:
-
_MAP001.png
3 KB
So, nun hats endlich funktioniert! :D Zumindest kann ich jetzt mal einen Bitstrom senden. Im Anhang seht ihr dazu nochmals ein Screenshot von meinem Oszi. Wie genau läuft das jetzt mit dem Empfangen ab? Den Code dazu kenn ich jetzt ja auch schon, allerdings weiss ich nicht wie ich das handhaben muss. wird beim Empfangen des Codes ein Interrupt ausgelöst, oder muss ich im Programm explizit auf das Clock- Signal warten? Ich bin mir zu 80% sicher bei der Sache mit dem Interrupt, alles Andere macht meiner Meinung nach nicht gerade viel Sinn. Andi PS: Kleines Rätsel: Was für einen Code sende ich? ;-)
hallo liebe Forengemeinde , hallo Andi , ich kämpfe zur zeit am selben problem ... mein ziel ist es , daten zwischen 2 AVR , mit shiftout / in auszutauschen . @Andi auf deinem Bild erkennt man das clock signal am kanal 1 und die daten auf kanal 2 , mir kommt aber der flicker in deiner datenleitung kurz vor dem 1. clock etwas komisch vor ? hast du da einen wackler in der leitung ? welchen delay wert verwendest du? ich sende im Augenblick bei 8MHz Quarz mit einem delaywert von 100 , es geht auch mit 10 , aber zu testzwecken erkennt man es so besser auf dem Oszi. Bei meinem Shiftin kommen die daten zwar an , aber ich muß sie mit Shift wert , Right , 1 erst "richten" also in die richtige reihenfolge bringen !? hat dafür jemand eine erklärung ? der Code ist im Anhang wie gesagt , so funktioniert es , aber das die daten "verdreht" sind ist ja nicht korrekt. wäre schön wenn jemand eine idee hat. Danke Sven
Hallo , ich habe soeben gemerkt das ich den shiftin code vergessen habe. der kommt nun hier. Sven hier könnt ihr mal auf meiner bastel HP vorbeischaun ... www.svens-projekte.de
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.