In einem meiner Designs verwende ich zum ersten mal einen PIC (konkret einen PIC18F6527) und ich habe dazu ein paar Fragen welche ich im Datenblatt nicht beantwortet finde.
- Ich verwende eigentlich nur die beiden "Master Synchronous Serial Port (MSSP)". Was mache ich mit allen anderen nicht verwendeten (Port)pins? Kann ich diese einfach offen lassen (nicht anschliessen)? Im Datenblatt steht an einigen Orten dass Portpins mit einem internen pull up versehen werden können. Das (oder als Output konfigurieren) müsste doch eigentlich reichen - oder?
- Eigentlich bräuchte ich keinen externen Oszillator. Ich muss nur I2C Kommandos von einem Master mit dem einen MSSP als Slave lesen, diese umformen und dann als Master auf dem zweiten MSSP wieder ausgeben. Dies bedingt aber doch etwas Software, da die Umformung nicht ganz ohne (aber nicht zeitkritisch) ist. Der ICD2 Debugger von Microchip will wie's scheint einen Oszillator. Da stellt sich die Frage ob damit zwingend ein externer gemeint ist oder der interne auch reichen würde?
- Da ich ausser der erwähnten Peripherie nichts verwende (insbesondere auch nicht den ADC), brauche ich trotzdem eine spezielle Versorgung für die analogen Versorgungspins und AGND? Beide müssen gemäss Doku des ICD2 von Microchip angeschlossen sein.
Wird schon vom Datenblatt beantwortet. Was die on chip hardware angeht, folgen die Darlegungen im datasheet bei microchip stets folgender Struktur:
- Erst erklärt, was es macht.
- Dann erklärt, wie es das macht (schematic).
- Initialisierung verwendeter portpin und Register.
- Dann Beispielcode in Assembler
- Tabellarische Zusammenfassung aller verwendeten Register und portpin.
Das Schema wird ziemlich strikt durchgehalten, sehr sinnvoll wenn man mal was nachgucken muss. Langes herumblättern entfällt dann.
steht auch immer im ds, ist bei der HW u.U. unterschiedlich.
*In der Regel* initialisierst du diese portpin via TRIS als input. Wenn die HW einzelne pin des Ports dann als output verwendet, schaltet die HW automatisch um. (Was am pin dranhängt, musst du natürlich richtig stricken...)
*Im Besonderen* kann das abweichen, steht aber immer im ds (in der Reihenfolge, wie oben geschrieben).
(Eigentlich braucht man es nicht schreiben, weil es für jedes ds gelten sollte (welcher Ing schreibt schon gerne Doku?): Das datasheet ist sprachlich komprimiert, wenig Redundanz, langsamer und sorgfältig lesen hilft. Jeder Satz hat Bedeutung. Eigentlich logisch.)
Schade eigentlich, dass Thomas Mann keine ds geschrieben hat.
Das machst du selbst nur, wenn du es für deine ext. Beschaltung brauchst und dir externe pull-ups sparen willst (und gilt doch nur für PortB, oder?). Ansonsten ignorierst du das, verbraucht unnötig (wenig) Strom.
Ja, brauchst du wohl nicht, jedenfalls nicht wg. genauer Zeiten.
ist unnötiger Luxus. Kleine, funktional eindeutig definierte (Schnittstellen) und leicht testbare Module einmal im Simulator laufen lassen führt viel schneller zum Ziel als sich duch Debuggergemüll durchzuarbeiten, IMHO.
Da sind noch andere Einschränkungen/Seiteneffekte, soweit erinnerlich. Debugger hindert nur bei so nem kleinen Controller.
Nein, steht auch im ds. Den AD auch komplett ausschalten wg. Stromverbrauch, steht alles im Abschnitt AD-Wandler.
Wenn du dich im Wesentlichen mit dem Debugger befassen willst, musst du das wohl so machen. Wenn du im Wesentlichen einen PIC programmieren möchtest, gibt es einfachere Methoden.
Ein Debugger mag sinnvoll/notwendig sein bei grösseren Controllern und wenn man in Hochsprache programmiert, aber nicht bei so einem kleinen Teil.
Nochmal: Dekomponiere deine Anforderungen in Module, spezifiziere die Module funktional und was deren Schnittstellen angeht. Und dann schreibe kleine, in sich testbare Module und teste diese hinsichtlich deiner Spezifikation im Simulator. Danach bau alles zusammen und fertig.
65% der Zeit überlegt und skizziert und 35% der Zeit implementiert und getestet --> kein debugger nötig beim PIC und du bist in T Stunden fertig.
5% der Zeit vorab überlegt, gleich wild losgehackt und 30% der Zeit implementiert, bleiben 65% der Zeit für Fehlersuche was einerseits lästig ist, unbestimmte Zeit braucht und womöglich findest du gar nicht alle Fehler, vor allem nicht die strukturellen oder konzeptionellen Fehler. Die aufgewendete Zeit, wenn du es so machst, wird leicht ein Vielfaches von T!
Und die Zeit, sich mit dem Debugger vertraut zu machen und seine Eigenheiten kennenzulernen kommt auch noch dazu.
Der Vollständigkeit halber: Eigentlich fängt man auch nicht mit den Hardwaredetails an, das ist Sache der Implementierung; nachgeordnetes Detail.
Man dekomponiert die HW Anforderungen I/O so, dass dein Assembler- programm leicht an einen anderen PIC angepasst werden kann, d.h. nur wenige/nur ein Schnittstellenmodule sind/ist hardwareabhängig (Init kommt noch dazu) und muss ggf. angepasst werden.
Hinweis im Header auf abhäng. Module nicht vergessen.
Ausser Initialisierungsmodul in deinem Fall vielleicht die Module "I2C_In" und I2C_out", der Rest der SW sollte dann PIC-Typunabhängig sein.
Fehlt dem nächsten PIC die HW, dann werden diese beiden Module eben komplett in Software geschrieben und fertig.
(Stichwort: Informationen kapseln, nicht im ganzen Projekt verstreuen.)
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.