June 22, 2013 at 02:55 PMJun 22, 2013 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
June 24, 2013 at 01:14 PMJun 24, 2013 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?
June 25, 2013 at 02:25 PMJun 25, 2013 Author 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.
June 26, 2013 at 11:47 AMJun 26, 2013 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!
July 1, 2013 at 10:42 AMJul 1, 2013 Author 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
July 1, 2013 at 05:37 PMJul 1, 2013 - 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 .
July 5, 2013 at 08:30 AMJul 5, 2013 Author 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!
July 5, 2013 at 09:43 AMJul 5, 2013 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.
July 9, 2013 at 12:58 PMJul 9, 2013 Author 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ß
July 9, 2013 at 02:24 PMJul 9, 2013 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)?
July 9, 2013 at 02:38 PMJul 9, 2013 Author Das Bootloader Problem hat sich gerade behoben. Anscheinend war es doch nur eine kalte Lötstelle Danke Trotzdem.
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.