davidkoch Geschrieben June 22, 2013 at 14:55 Share Geschrieben June 22, 2013 at 14:55 Hallo zusammen, ich habe bin an der Entwicklung eines eigenen Bricks der CAN und LIN Bus anschluss hat. Die Hardware ist bereits fertig und das System implementiert. Habe einen ATSAM3S4C also genau den gleichen wie den Master drauf, welcher die SPI Slave routine laufen lässt. Momentan bin ich stehe ich bei dem Punkt das die SPI routine die Nachrichten vom Master nicht Richtig empfängt, welches am Timing liegt. Wenn ich die zeilen mit dem Pearson hash auskommentiere passt es. Daraus ziehe ich die vermutung, das bie berechnung der checksum an einigen stellen zu lange dauert. Da der gleiche Controller verwendet wird wie der Master denke ich, das es an den Clockeinstellungen liegt. Habt ihr eine Idee an welcher stelle ich dort drehen muss? Oder vll hat jemand schonmal das gleiche Problem gehabt? Gruß David Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
borg Geschrieben June 24, 2013 at 13:14 Share Geschrieben June 24, 2013 at 13:14 Mh, die Konfiguration der Clock findet in bricklib/drivers/board/board_lowlevel.c in low_level_init statt: https://github.com/Tinkerforge/bricklib/blob/master/drivers/board/board_lowlevel.c Nutzt ihr einen externen oder den internen Quarz? Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
davidkoch Geschrieben June 25, 2013 at 14:25 Autor Share Geschrieben June 25, 2013 at 14:25 ich verwende einen externen 16MHz quarz. Die lowlevel routine ist exakt die gleiche wie beim master brick. Das Problem besteht bisher weiterhin, konnte ich doch durch den Wert SPI_DELAY_BETWEEN_TRANSFER = 1000 im Master Brick beheben. Allerdings ist die einstellung nicht optimal. So braucht natürlich die Kommunikation deutlich länger als zuvor. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
borg Geschrieben June 26, 2013 at 11:47 Share Geschrieben June 26, 2013 at 11:47 Schwer zu sagen was da passiert. Hast du einen Logic Analyzer da? Mein vorgehen hier wäre jetzt die SPI-Kommunikation einmal komplett aufzunehmen, um zu gucken wo genau etwas schief geht. Optimalerweise würdest du für das Debuggen noch ein paar zusätzliche GPIO Pinne nutzen um anzuzeigen wann CAN/LIN-Bus Kommunikation beginnt/endet etc. Damit kannst du dann gucken ob es dort Überschneidungen gibt o.ä. die zu Problemen führen! Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
davidkoch Geschrieben July 1, 2013 at 10:42 Autor Share Geschrieben July 1, 2013 at 10:42 Hallo, so. Also das Problem besteht weiterhin. Ich hab mal die Bilder vom LogicAnalyzer angefügt. Beim Wert SPI_DELAY_BETWEEN_TRANSFER = 0 funktioniert es nicht. Beim Wert 500 sieht man das der Slave das CRC Byte zu spät überträgt. Beim Wert 1000 funktioniert es. Und der Slave sendet auch die Ack. - Die Clock habe ich mittlerweile Überprüft. - Problem beim Nutzen eines GPIOs ist, das diese sehr langsam an aus geschaltet werden. - Des weiteren habe ich im Master Brick eine Funktion implementiert die mir die anzahl der Übertragungen anzeigt. dabei auch die fehlerhaften, leeren, und erfolgreichen. Dabei ist aufgefallen, das bei meinem (mit einstellung 1000 s.o.) sowie auch bei den anderen Bricks zu beginn 11 Fehl übertragungen passieren.?! Gruß David Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
borg Geschrieben July 1, 2013 at 17:37 Share Geschrieben July 1, 2013 at 17:37 - Des weiteren habe ich im Master Brick eine Funktion implementiert die mir die anzahl der Übertragungen anzeigt. dabei auch die fehlerhaften, leeren, und erfolgreichen. Dabei ist aufgefallen, das bei meinem (mit einstellung 1000 s.o.) sowie auch bei den anderen Bricks zu beginn 11 Fehl übertragungen passieren.?! Du meinst ganz am Anfang beim starten? Das ist OK. Damit überprüfen wir ob und wie viele Stack-Teilnehmer vorhanden sind. Die Frage bleibt im Prinzip: Macht dein CAN/LIN-Bus Code irgendwas, was den Slave davon abhält rechtzeitig zu antworten? Funkt ein Interrupt dazwischen o.ä.? Wenn der SPI-Slave Interrupt getriggert wird und einfach durchläuft ohne unterbrochen zu werden und du verwendest unseren Code für die SPI Slave Kommunikation muss es funktionieren. Ich sehe kein Grund warum das nicht gehen sollte . Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
davidkoch Geschrieben July 5, 2013 at 08:30 Autor Share Geschrieben July 5, 2013 at 08:30 Hallo, Nein eigentlich sollte der Controller nichts machen. durch __disable_irq(); und__enable_irq(); sollten auch in der slave routine alle interrupts ausgeschaltet werden oder?! vielen dank schonmal für die rückmeldung! Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
borg Geschrieben July 5, 2013 at 09:43 Share Geschrieben July 5, 2013 at 09:43 Also der Code für die SPI Slave Kommunikation ist unmodifiziert? Dann verstehe ich das nicht, warum sollte sich der Code auf einmal anders verhalten . Die __disable_irq(); und__enable_irq(); schalten Interrupts aus/an, das ist richtig. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
davidkoch Geschrieben July 9, 2013 at 12:58 Autor Share Geschrieben July 9, 2013 at 12:58 Ja. Die Interruptroutine habe ich auch nicht verändert das finde ich auch komisch.. naja erstmal funktioniert es eingeschränkt. Andere Frage, gleicher Topic: Ich habe wahrscheinlich den Bootloader ereased. Wie bekomme ich den nun wieder geflasht? Per JTAG komme ich auf den SAM3S allerdings per USB wird er nicht erkannt. Gibts den Bootloader zum download? Gruß Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
borg Geschrieben July 9, 2013 at 14:24 Share Geschrieben July 9, 2013 at 14:24 Der Bootloader steht bei den sam3s Mikrocontroller in einem "read-only" Bereich, den kann man nicht löschen. Er ist also definitiv noch da. Hast du schon versucht beim anstecken des USB Steckers den Erase Knopf zu drücken (um sicher zu gehen das er auch wirklich im Bootloader ist)? Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
davidkoch Geschrieben July 9, 2013 at 14:38 Autor Share Geschrieben July 9, 2013 at 14:38 Das Bootloader Problem hat sich gerade behoben. Anscheinend war es doch nur eine kalte Lötstelle Danke Trotzdem. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.