Hallo liebes Forum,
Ich habe eine Frage, da ich mir gerade etwas unsicher geworden bin..
Es geht um einen dsPIC33
Folgendes Szenario:
Ich möchte gerne binär die Pins aus PORT A einstellen ob diese Eingänge
oder Ausgänge sind.
Was ist wenn es Pins nicht gibt bzw nicht angeschlossen sind? zbsp RA2
und RA3 ?
Ich kennzeichne mal mit x die Pins die es nicht gibt:
TRISA = 0b11x1101xxxx0xx11
Das kann ich ja so nicht schreiben, bzw das x wird nicht angenommen.
Dann hab ich gelesen dass standard mässig alle Pins auf Eingang gesetzt
sind. Also würde das so aussehen:
TRISA = 0b11111011111011
Ist das richtig so ?
Würde mich auf eine Antwort freuen
vielen dank
-derneue
derneue schrieb:> TRISA = 0b11111011111011>> Ist das richtig so ?
Ganz allgemein:
Schreib die vollen(!) 16bit.In den Positionen fuer nicht(!)
implementierte Pins,kannst Du reinschreiben was Du willst => "0" oder
"1"(keine Buchstaben wie "x" - da wuerde sowieso der Compiler
meckern).Diese Werte werden vom uC ignoriert.
Sind aber alle Pins vorhanden und verwendest nur einige davon nicht,gilt
auch hier alle 16bits anzugeben UND sinnvollerweise die Pins z.B. als
Ausgaenge zu konfigurieren.Man kann sie auch als Eingaenge
verwenden,aber dann musst Du auch dafuer sorgen,das sie mit internen
oder externen Pull-ups versehen werden.Schwebende Eingaenge mag kein
uC.....
Oh ja klar, hab da wohl beim abtippen falsch mitgezählt, natürlich
sollen es 16 bit sein..
Okay Danke, das wollte ich wissen. War mir unklar was reinkommt für
nicht existierende Pins, warum auch immer das so gemacht wird.
Ne andere Frage: bei mir meckert der Compiler wegen der binären 16 bit
TRIS zuweisung:
"large integer implicitly truncated to unsigned type"
Mir ist klar dass er meckert weil der Wertebereich überschritten wird,
aber wo kann ich denn den Typ von TRISA , TRISB etc ändern? Das ist doch
in der MikroController spezifischen header datei niedergeschrieben. Da
kann ich doch nicht anfangen rumwurschteln zu gehen, wenn doch der
richtige Controller ausgewählt ist ?
Vielen dank
OK ist gelöst! Hatte ein bit zu viel drin. Ist wohl zu spät und meine
Augen werden müde haha
Hätte ja sonst auch kein Sinn ergeben da ich in der entsprechenden
Header Datei nachgeschaut habe und es ein unsigned int war.
Vielen dank für deine Hilfe, hast mir paar Gedankenanstöße gegeben!
Liebe Grüße,
-derneue
derneue schrieb:> TRISA = 0b11111011111011
Ich würd die Bits, immer da wo sie gebraucht werden, einzeln setzen. Das
macht das ganze besser lesbar.
TRISAbits.TRISA0 = 1;
Da bekommt man auch gleich einen Fehler, wenn bei dem Chip den man
nutzt, das Bit nicht existiert.
MfG Klaus
Klaus schrieb:> derneue schrieb:>> TRISA = 0b11111011111011>> Ich würd die Bits, immer da wo sie gebraucht werden, einzeln setzen. Das> macht das ganze besser lesbar.>> TRISAbits.TRISA0 = 1;>> Da bekommt man auch gleich einen Fehler, wenn bei dem Chip den man> nutzt, das Bit nicht existiert.>> MfG Klaus
Genau, das der richtige Weg.
Microchip hat das im Header als Bitfeld aufgelegt. Wenn man wissen will,
wie es funktioniert, in den Headern ist alles Klartext. Rechtsklick auf
"TRISBbits" und "jump to definition".
Im Datenblatt das bit suchen ist nicht nötig.
Ich tu das immer so:
1
#define Blinkled_1 LATBbits.LATB1
2
#define tris_Blikled_1 TRISBbits.TRISB1
3
4
tris_Blikled_1=0;
5
Blinkled_1=1;
6
Blinkled_1=0;
Das erhöhte die Wiederverendbarkeit des Codes, weil man bei einem
anderen Board nur ein einzelnes #define anpassen muss, schon läuft das
mit einem andern PIC oder einem anderen Layout.
Bummsfallera schrieb:> Ich tu das immer so:> #define Blinkled_1 LATBbits.LATB1> #define tris_Blikled_1 TRISBbits.TRISB1>> tris_Blikled_1 = 0;> Blinkled_1 = 1;> Blinkled_1 = 0;>> Das erhöhte die Wiederverendbarkeit des Codes, weil man bei einem> anderen Board nur ein einzelnes #define anpassen muss, schon läuft das> mit einem andern PIC oder einem anderen Layout.
Genau so mach ich das auch
MfG Klaus
Okay vielen dank für die tollen Tipps. Das alles einzeln auszuschreiben
bringt aber viele Code zeilen auf die Waage.. Komischerweise lese ich in
den Code beispielen überall nur dass per Hex einfach das ganze Register
gesetzt wird, ohne jeden Pin einzeln zu setzen.
Habs in der Header Datei nachgeschaut, ist schon praktisch da man wie
Bummsfallera schon sagte nicht mehr ins Datenblatt schauen muss. Aber
eigtl müsste der Compiler das doch richtig handhaben wenn per binärer
Schreibweise ein Bit gesetzt wird obwohl es ein Pin nicht gibt?
derneue schrieb:> Habs in der Header Datei nachgeschaut, ist schon praktisch da man wie> Bummsfallera schon sagte nicht mehr ins Datenblatt schauen muss.
Man muß nicht mal in der Headerdatei nachschauen. Wenn man den Namen des
Registers weit genug eingetippt hat, schlägt einem die IDE schon mal
alle vorhandenen Bits oder Bitfelder vor. Man muß dann nur auswählen.
derneue schrieb:> Das alles einzeln auszuschreiben> bringt aber viele Code zeilen auf die Waage..
Na und? Ist dein Speicher knapp?
derneue schrieb:> Komischerweise lese ich in> den Code beispielen überall nur dass per Hex einfach das ganze Register> gesetzt wird, ohne jeden Pin einzeln zu setzen.
Damit will der Programmierer nur zeigen, daß er ein ganz harter ist.
Chuk Norris schreibt seinen Code gleich binär hin.
Und nein, der Compiler weiß nicht, daß es einzelne Bits an einer
Speicherposition nicht gibt. Er weiß nur, daß für einzelne Bits kein
besonderer Name definiert ist. Man kann sie daher nicht mit Namen
ansprechenn.
MfG Klaus
Klaus schrieb:> derneue schrieb:>> Habs in der Header Datei nachgeschaut, ist schon praktisch da man wie>> Bummsfallera schon sagte nicht mehr ins Datenblatt schauen muss.>> Man muß nicht mal in der Headerdatei nachschauen. Wenn man den Namen des> Registers weit genug eingetippt hat, schlägt einem die IDE schon mal> alle vorhandenen Bits oder Bitfelder vor. Man muß dann nur auswählen.>> derneue schrieb:>> Das alles einzeln auszuschreiben>> bringt aber viele Code zeilen auf die Waage..>> Na und? Ist dein Speicher knapp?
Es braucht nicht mal mehr Speicher, wenn man nur einen Port setzt - was
der Normalfall ist. Was die Hexpfriemelei komplett überflüssig macht.
LATB |= 0x0002;
ist genauso viel (oder mehr!) Code wie
LATBbits.LATB2 = 1;
Ich täts halt im Disassembly mal vergleichen, da sieht man es dann
genau.
Dazu kommt:
Wer einen eigenen Codefundus für PIC32 aufbaut merkt schnell, dass das
Bitgepfriemel nicht praxistauglich ist.
Benutzt man ein #define für jeden Pin, ist der Code in Sekunden auf ein
neues Projekt portiert, wohingegen der Bit-Chuck-Norris mit dem Scope
vor der Platine sitzt und nicht findet, wo das Bit falsch gepfriemelt
wurde.
Ich weiß das, weil ihc das schon getan habe. Genau Einmal.
Apropos Performance:
Cache ist aktiv und Flash- und SRAM-waitstates sind gesezt? Ich frag
nur, das ist ein fieser Fallstrick bei PIC32. Das nicht zu tun kostet
satt Performance.
Ok liebend dank an alle. Habe mir mal Gedanken drüber gemacht, und finde
es jetzt auch besser alles per define zu setzen. Sieht auch schon viel
übersichtlicher aus und wird es tatsächlich für ein neues Layout
einfacher machen.
Ich habe das jetzt so gemacht:
Ich habe eine board.h und eine board.c , wo die ganzen Pins konfiguriert
werden.(folgendes nur als beispiel)
In der Board.h :
#define TRIS_D1 TRISAbits.TRISA01
#define ANSEL_D1 ANSELAbits.ANSA01
#define D1 PORTAbits.RA01 //zum Abfragen
Und in der Board.c :
TRIS_D1=1;
ANSEL_D1=0;
D1 wird dann irgendwo in der main.c benutzt..
Ehm zur Performance:
Weiß ich noch nicht, hab die config Bits noch nicht eingestellt. Wollte
dies eventuell über den "Bitkonfigurator" in MPLAP machen, muss mich da
aber noch einlesen was da genau alles eingestellt werden muss.
LG
