Ja, die kleinen Fehler sind immer die gemeinsten. Das war ungefähr das Motto der letzten Runde Entwicklung an meinem ftRoboExt.
Wie üblich bei solchen gemeinen Problemen war der Fehler schwer einzugrenzen, ab und zu funktionierte die SPI-Verbindung zum Robo Interface ohne Probleme, in den meisten Fällen tat mein Controller aber gar nichts. Es lag natürlich an eigener Blödheit, ich hatte das Datenblatt nicht richtig gelesen, dort steht es im Abschnitt 19.3.1
When the SPI is configured as a Slave, the Slave Select (SS) pin is always input. When SS is held low, the SPI is activated, and MISO becomes an output if configured so by the user. All other pins are inputs. When SS is driven high, all pins are inputs, and the SPI is passive, which means that it will not receive incoming data. Note that the SPI logic will be reset once the SS pin is driven high.
Beim ftRoboExt ist der AVR ein Slave und in diesem Modus ist der /SS-Pin immer ein Eingang und das SPI-Modul funktioniert nicht, wenn er nicht auf Low liegt. Ich hatte das beim Layout der Platine nicht bedacht und die ADDR1 Leitung des Busses auf diesen Pin geroutet, daher hat das SPI-Modul nur dann funktioniert, wenn gerade eine Adresse anlag, die dort eine Null hatte. Nachdem ich die Leitung dauerhaft auf Ground gelegt hatte, funktioniert das SPI-Modul auch wunderbar, und erste Werte sind in RoboPro zu sehen:
Jetzt muss ich mir noch überlegen, wie ich das Problem dauerhaft löse. In jedem Fall werde ich den Pin am Controller verlieren, was sehr ärgerlich, weil mein Modul so nur noch die ADDR0-Leitung auslesen kann, und damit die Möglichkeit verliert, als mehr als ein Modul zu agieren (unter den Adressen 0-2 oder so). Ich hatte noch ein paar tolle Ideen, was man mit einem virtuellen Modul machen könnte (ich sage nur EEPROM und I2C…), aber das fällt jetzt wohl weg. Mal sehen, vielleicht fällt mir noch etwas dazu ein. Dann muss ich noch eine Lösung finden, den Pin des Controllers dauerhaft auf Low zu legen, ohne ADDR1 des Bussen auf Low zu ziehen (wäre im Prinzip auch nicht schlimm da es ein OpenCollector Ausgang ist). Die einfachste Lösung ist einfach den Pin auf dem Pfostenstecker mit dem Pin daneben zu verbinden, das ist nämlich zufällig Ground ;). Hat dann aber den Nachteil, das ständig ein Strom durch den Pull-Up fließt, aber die 3,3V / 10k Ohm = 0,3 mA werden auch niemanden umbringen :D. Sprich mit einer Lötverbindung ist das Problem gelöst!
Als längerfristige Lösung wäre es natürlich cool den neuen ATmega 328PB zu verbauen, der Pin-kompatibel ist, aber noch 2 GPIOs mehr hat (statt einem VCC/GND Paar). Der würde das Problem also genau lösen. Das habe ich mir mal für Revision 2 auf ;). Alles in allem Schade, dass der AVR hier so unflexibel ist, und sich der /SS-Pin nicht in Software abschalten lässt, so einen Pin, den man einfach auf Ground legt würde man doch gerne anders verwenden können. Na gut, das ein AVR mal Slave statt Master ist, und es dann auch noch keinen anderen Slave gibt, so dass man auf SlaveSelect verzichten kann, ist vielleicht wirklich etwas selten 😉
Noch ein paar Worte zu meiner aktuellen Entwicklungsumgebung: Den Code schreibe ich aktuell in Arduino, mit mehr oder wenig Low-Level-Zugriff (Arduino hat z.B. keine Bibliothek für SPI-Slaves und kann den XTAL1 Pin nicht als GPIO nutzen). Der Code wird dann mit meinem mySmartUSB MK2 hochgeladen (über deren Tool, weil die avrdude nicht richtig unterstützen). Leider sind die ISP-Pins des Controllers die gleichen, an denen auch der SPI-Bus zum Robo-Interface hängt. Praktischerweise kann man den Programmer aber auch 3,3V einstellen und durch die OpenCollector-Ausgänge und des Interfaces und die Tatsache das sich der Programmer passiv verhält, wenn er nicht gebraucht wird, kann man das aber tatsächlich alles ohne umstecken benutzen. RoboPro zeigt während des Programmierens immer kurz komische Werte an, scheint aber den Vorgang nicht zu stören.
Was ich wirklich während meiner Bachelorarbeit schätzen gelernt habe, sind LogicAnalyzer: Damit macht das Debuggen von Bussen einfach so viel mehr Spaß… Natürlich habe ich hier nicht den coolen 2GSa/s Analyser von meinem Institut hier, aber immerhin reicht ein Arduino für 4MSa/s: Man nimmt einfach diesen Sketch und den dort verlinkten Client, und schon hat man einen LogicAnalyzer mit immerhin 8 Kanälen, 4 Megasamples/Sekunde Auflösung und ein paar tausend Samples Speichertiefe, dazu einen einfachen Trigger. Das ist nicht viel, aber bedeutend praktischer als ohne LogicAnalyzer, und so einen Arduino hat man ja meistens eh noch rumliegen 😉
Schlussendlich sieht der Aufbau aktuell so aus:
Alles Signale laufen auf dem Breadboard zusammen, der Arduino Mega ist der Logic Analyzer. So sieht das dann übrigens in dem Client aus:So viel an zufälligen, unkoordinierten Gedanken zum Thema ftRoboExt. Mein nächstes Ziel ist es jetzt, den Code so weit fertig zu schreiben, dass die Ein- und Ausgänge komplett funktionieren. Mal sehen, was dort noch an kleinen Gemeinheiten lauert 😉
2 Gedanken zu „ftRoboExt: Fortschritt“