Hallo liebe Profis,
nach fast 30 Jahren Abstinenz mit der Programmiererei (damals noch
BASIC), habe ich weite Welt der PICs für mein Modellbahnhobby entdeckt.
Es ist sehr viel schwieriger als ich zunächst annahm.
Ich studierte inzwischen viele Beispielprogramme, insbesondere bei
sprut.de und , soweit für mich verständlich, in diesem Forum.
Man beginnt natürlich mit einfachen Programmen, um hinter die
Geheimnisse zu kommen. Nach vielem erfolglosen probieren, bitte ich um
einen Hinweis, warum mein kleines Progrämmchen nicht funktioniert. Hier
handelt es sich um ein einfaches Ansteuern von Ausgängen in Abhängigkeit
einer Belegung an den Eingängen. Eine Taste drücken --> eine LED an.
Ich glaube ich habe in der Initialisierung alle GP auf digital (CMCON)
gesetzt, die Ein- bzw Ausgänge in TRISIO eingetragen und die pull-ups
für GP3 bis 5 eingeschaltet (WPU und OPTION_REG). Ich nahm bisher an,
das damit, ohne eine Taste zu betätigen die Eingänge auf logisch 1
liegen. Ich frage nun die Eingänge mit btfss ab. Im Falle es liegt 1 an
(was keiner Taste gedrückt entspricht) erwarte ich, dass der nächste
Befehl übersprungen wird.
Leider macht das Programm das nicht und arbeitet den Befehl in der
darauf folgenden Zeile ab.
Der Fehler liegt nicht im PIC sondern sitzt davor. Ich habe also einen
Fehler in den Initialisierungen oder in meinem Verständnis.
Ich hoffe auf einen für mich hilfreichen und verständlichen Tipp. wo
mein Fehler liegt.
Mit freundlichem Gruß
Rudolf.
Hi,
nur ein hinweis, benutze doch in mplapx den simulator, weil dort kannst
du dir in ruhe step by step alle resourcen/sfr änderungen in jedem
programschritt anschauen.
ich habe deine source in 2 minuten als mplabx projekt am laufen gehabt.
... und dann siehst du schnell wo es hackt!
ich würde auch eher c-programming andenken, ich finde den einstieg dann
wesentlich leichter, da besser lessbar und später auch noch
nachvollziehbar. ausserdem gibt es tonnen von beispielen im netzt zu
finden.
am ende kommt es auf jedes bit an was man setzt oder auch nicht und
daher ist das handbuch irgendwann pflichtlektüre.
ich orakel - den fehler findest du an einen abend (15min habe ich
investiert )... mit dem simulator und du hast danach wesentlich mehr
spass mit neuen projekten!
das sollte doch genug motivation sein, jetzt die tools zu installieren?!
mt
... und für factory calibration bitte hinzufügen
OSCCAL = _READ_OSCCAL_DATA(); //get factory calibration value
bzw. varianten mit eigenen werten
//OSCCALbits.CAL0 = 1; //own calibration value for int. osc
//OSCCAL = 0x018; //set CAL2 and CAL1
mt
Apollo M. schrieb:> ... und für factory calibration bitte hinzufügen>> OSCCAL = _READ_OSCCAL_DATA(); //get factory calibration value
soweit ich die Doku des XC8 verstehe, macht er das im Startup-Code schon
automatisch, wenn man es ihm nicht ausdrücklich verbietet.
Apollo M. schrieb:> und hier noch die version in c für xc8 compiler
diese Version macht nicht das gleiche, wie die Asm-Version - die
C-Version schaltet nämlich die LEDs nur ein und nie wieder aus!
... calibration
ja, in mplabx läßt sich unter project properties/xc8 linker die
calibration option auswählen und auch ein user value eintragen.
ich finde es aber transparenter direkt im code. ich benutze of ja eh
schon code um z.b.
- die calibrierung in abhängigkeit von der temperature zu ändern oder
- geignete "krumme" osc werte (wie z.b. 8.192MHz statt 8MHz) zu erhalten
um z.b. geringere zeitfehler mit timern zu bekommen.
die fuse bits (config) sind für mplabx auch nicht direkt im code
notwendig, weil diese im project file hinterlegt werden, aber ohne
direkt im code ist es weniger portable/re-usable.
... automatische variante?! keine ahnung kenne ich nicht. erzähl mal
bitte mehr dazu.
hinweis, es gibt "medizin" um den xc8/16/32 im pro mode laufen zu
lassen,
so ist der c-code hier z.b. nur 3 byte länger als die asm variante.
entscheident bzgl. code size ist aber oft eher wie das problem codiert
wird. einige program snippets meiner projekte habe ich gefühlt 100mal
neu geschrieben und es wurde immer besser bzgl. size/speed aber auch die
code ästhetik.
den mplabx simulator kann ich als startpunkt/-hilfe empfehlen, wobei
dieser auch einige einschränkungen und fehler hat.
wie immer geht viel zeit drauf, um mit den tools erstmal anfangen zu
können.
ich finde, die pic's haben oft wesentlich umfangreichere on-chip
peripherie als avr's ...
meine recht komplexen lieblinge sind:
- CTMU Charge Time Measurement Unit
- SMT 2 x 24-bit Signal Measurement Timer
- DSM Data Signal Modulators
- NCO Numerically Controlled Oscillator
der pic cpu core erscheint etwas "krank" mit pros und cons.
zum datenschaufeln eher nicht, aber für embbeded control wieder genial
geeignet.
ich lerne immer wieder gerne dazu und lese deshalb oft den code von
anderen projekten. interessante details erkennt man so oft immer
schneller.
z.b. benutzt kaum einer die genialen gpio register der avr's um flags in
bit struktruren zu packen die sehr geringe code size generieren, da in
diesen adressbereich bit befehle erzeugt werden UND bei reset diese via
hw zurückgesetzt werden.
mt
... diese Version macht nicht das gleiche, wie die Asm-Version - die
C-Version schaltet nämlich die LEDs nur ein und nie wieder aus!
korrekt - danke thomas!
das sollte eigentlich sofort aufleuchten, da in dem program
bit-orientiert auf das gpio zugegriffen wird.
als finderlohn attached nun eine variante, die die leds toggled, wenn
... related button was pressed.
so etwas unterstützt heute fast jeder controller in hw. also die
erkennung, ob eine H-L oder L-H flanke vorliegt und bzgl. der quelle die
port pinzuordnung.
mt
Rudolf schrieb:> habe ich weite Welt der PICs für mein Modellbahnhobby entdeckt.> Es ist sehr viel schwieriger als ich zunächst annahm.
Du machst es Dir nur unnötig schwer, wenn Du mit dem veralteten PIC12
anfängst.
Nimm ab PIC18 aufwärts, da fallen viele Einschränkungen weg, d.h. das
Programmieren ist deutlich komfortabler und er hat auch weniger
Fallgruben. Und er ist oftmals auch billiger als die Museumstypen.
Besonders bequem ist ein PIC18 mit USB-Bootloader.
Apollo M. schrieb:> ... automatische variante?! keine ahnung kenne ich nicht. erzähl mal> bitte mehr dazu.
Das Manual zum XC8-Compiler erzählt dazu im Abschnitt "Library
Functions", bei "__OSCCAL_VAL":
"Note that this function is automatically called by the runtime start-up
code (unless you have explicitly disabled this option, see Section
4.8.54 '--RUNTIME: Specify Runtime Environment') and you do not need to
call it to calibrate the internal oscillator."
... pic18?
ja und nein, weil die advanced core types gibt es nur mit 20/28/40 pins
und daher haben pic10/12/16 einen guten daseinsgrund.
die umfangreichste on-chip pheripherie haben pic16, wobei pic18 immer
mehr nachrüstet.
pic18 kommt dafür mit mehr mips, doppelten stack, befehlserweiterung,
events system, besseres interrupt system, hw multiplizierer, ... daher.
wenn pic18 dann k42 typen andenken, z.b. das monster pic18lf26k42.
als orientierung mal ideen für pic's bis 18pins und besser immer die lf
variante andenken!
- pic10 (6pin): pic10f322
- pic12 (8pin): pic12f1572, pic12f1612, pic12f1822, pic12f1840
- pic16 (8pin): pic16f18313
- pic16 (14pin): pic16f18326, pic16f1825, pic16f1615
- pic16 (18pin): pic16f819, pic16f1455
key ist welche on-chip peripherie ich brauche - und auch anwenden kann.
wie z.b. mit 5/8/10bit dac, 10 oder 12bit adc, 8/16/24bit timer,
10/12/16bit pwm, ...
wer steuern/messen und/oder regeln will ... für den lohnt es sich
besonders pic's mit dieser on-chip peripherie auszusuchen UND sich damit
intensiv zu beschäftigen:
- CTMU Charge Time Measurement Unit
- SMT 2 x 24-bit Signal Measurement Timer
- NCO Numerically Controlled Oscillator
- DSM Data Signal Modulators
die low power funktionen sind auch eine stärke der pic12/16 und toppen
oft pic18 und attiny/atmega - wenn man die entsprechenen funktionen
richtig einsetzt.
mt
p.s. um mal eine idee zu bekommen, wie umfangreich die pic on-chip liste
ist ...
PPS Peripheral Pin Select
PMD Peripheral modul disable
PRG The Programmable Ramp Generator
HLVD High/Low-Voltage Detection
DSM Data Signal Modulators
SMT 2 x 24-bit Signal Measurement Timer
OPA Operational Amplifiers
ADC 12bit
DAC 10-bit
ZCD Zero Cross Detection
LVD Low-Voltage Detection
I/O 2x100mA
I/O 1x50mA
RS-485 EUSART
CLC 3-4x Configurable Logic Cell
SR Latch Emulates 555 Timer applications
PRG Programmable Ramp Generator
PSMC Programmable Switch Mode Controller
AT Angular Timer
HLT Hardware Limit Timer, Timer Trigger Mode
CRC/SCAN Cyclic Redundancy Check with Memory Scan
PID Programmable PID controller
ADC2 ADC with Computation
MathACC Math Accelerator
POR Power on Reset
CTMU Charge Time Measurement Unit
ULPWU Ultra Low-Power Wake-Up
NCO Numerically Controlled Oscillator
CWG Complementary Waveform Generators
CVD Capacitive Voltage Divider
IVR Internal Voltage Regulator
ULPWU Ultra Low-Power Wake-Up
ID Internal Debugging without debug header
TIM TEMPERATURE INDICATOR
... OSOSCCAL = _READ_OSCCAL_DATA(); ?
also in mplabs projekten MUSS die linker option explizit ausgewählt
werden oder das makro im code aufgerufen werden. wenn der xc8 compiler
von der kommandozeile aufgerufen wurde, dann macht es der linker
automatisch.
danke für den hinweis thomas!
ich finde, dass ist irgendwie unlogisch, das mplabs die option off
gesetzt hat. daher meine empfehlung - besser im code explizit das makro
aufrufen.
will mal jemand sehen wie man auch mit wenig resourcen (pic12/16) "time
slice task priority management" realisieren kann um pseudo multi threads
zu implementieren?
damit man z.b in richtung "echtzeitfähigkeit" mit seiner anwendung gehen
kann.
also quasi parallel irgendwas in richtung
- ui bedienen (anzeige, keys, beep sound)
- daten holen, verschicken
- rumrechnen
- sensoren abfragen
- ...
mt
Hallo majortom,
vielen Dank für deine Listings und die vielen Hinweise.
Die C-Listings sehen tatsächlich einfacher und verständlicher aus. Ich
denke intensiv darüber nach, meinen inneren Schweinehund zu töten und
mich intensiv mit C zu beschäftigen.
Das asm-listing und der natürlich zugehörge Blick in das Datenblatt trug
wesentlich zum Verständnis bei. Die Schreibweise wie z.B.
"movlw 1<<CM2|1<<CM1|1<<CM0" konnte ich bisher nirgendwo finden. Wie
das funtioniert ist mir klar, aber gibt es dazu irgendwelche
Literaturstellen für derartige Kurzformern?
Mit dankbarem Gruß
Rudolf.
Apollo M. schrieb:> ich finde, dass ist irgendwie unlogisch, das mplabs die option off> gesetzt hat. daher meine empfehlung - besser im code explizit das makro> aufrufen.
Stimmt - das ist verwirrend! Wenn man das Compiler-Manual liest, denkt
man, die Kalibrierung wird automatisch in den Startup Code eingebaut und
man geht davon aus, daß auch die IDE bei einem neu angelegten Projekt
erstmal die Compiler Default Settings vorgibt. Bin ich natürlich drauf
'reingefallen...
Rudolf schrieb:> nach fast 30 Jahren Abstinenz mit der Programmiererei (damals noch> BASIC), habe ich weite Welt der PICs für mein Modellbahnhobby entdeckt.> Es ist sehr viel schwieriger als ich zunächst annahm.
Wenn Du magst, kannst Du Dir ja auch mal mein PICALIC-Projekt
(www.picalic.de) angucken. Ist zwar ursprünglich eher für den
RC-Modellbereich entstanden und ein bisschen in die Jahre gekommen, aber
es kann natürlich auch Beleuchtungs- oder andere Steueraufgaben auf der
Modellbahnanlage übernehmen. Statt Servosignal kann man auch einfache
GPIO-Pins oder eine serielle Schnittstelle Steuersignal benutzen. Das
serielle Protokoll kennt auch eine Adressierung der einzelnen
Controller, so könnte z.B. jedes Haus einen PIC für die Beleuchtung
bekommen und man kann dann über eine einzige Datenleitung für alle
Häuser z.B. die Lichter im Haus, blinkende Leuchtreklamen,
Fernsehgeflacker im Wohnzimmer, das Leuchtfeuer im Leuchturm uva.
individuell schalten.
Warum muss man in der heutigen Zeit sich noch mit einem pic12f629
begnügen.
Und warum den ganzen Kram in Assembler programmieren?
Ich würde Ihnen einen modernen pic18f empfehlen. Dazu den Pickit 3 und
dann alles in C programmieren.
Der Compiler macht dann schon einen guten Assembler Code daraus.
Und man kann das ganze Programm viel Übersichtlicher gestalten.
Und auch die ganzen Funktionen die man benötigt schön vom restlichen
Programm trennen.
Mit freundlichen Grüßen
Norbert S. schrieb:> Warum muss man in der heutigen Zeit sich noch mit einem pic12f629> begnügen.
Man muss nicht, aber man darf, wenn man will. Man darf auch in Assembler
programmieren, wenn man eine eher Hardware-orientierte Denke hat und den
technischen Dingen bei der Ausführung seines Hobbys gerne auf den Grund
geht. So, wie manche Leute auch heute noch gerne ihre Modellflugzeuge
aus Holz bauen, wo andere auch fragen könnten: "warum tut man sich das
heute noch an, wo es doch so tolle Flieger von Hobbyking aus China fix
und fertig aufgebaut gibt, und das auch noch billiger, als die
Materialkosten in Deutschland?"
Wenn man Assembler kann, kann man auch das ASM-Listing des C-Compilers
lesen und ggf. den C Sourcecode umschreiben, damit besser optimierter
Code herauskommt (zumindest an kritischen Stellen). Assembler lernt man
aber nicht, wenn man nur in C programmiert.
Ich wollte auch schon mal jemanden vorschlagen, einen modernen
PIC12F1xxx statt 12F675 zu nehmen, der Mann hat dankend abgelehnt, weil
der Komparator beim 675er bessere Werte hatte. Un damit hatte er Recht!
So pauschale Empfehlungen "heute nimmt man besser die Cotroller-Familie
xy" sind grundsätzlich falsch.
Ein paar LEDs blinken lassen kann auch der 12F629, und dafür könnte man
ihn auch problemlos in C programmieren, dann braucht man sich um
Bankselects auch nicht zu kümmern. Seine Peripherie und deren
Programmierung ist bestimmt einfacher zu überblicken, als die der
PIC18-Familie, oder z.B. gar die eines STM32Fxxx (für diejenigen, die
meinen, 8-Bit wäre tot und heute nimmt man für egal was einen ARM).
Norbert S. schrieb:> Ich würde Ihnen einen modernen pic18f empfehlen. Dazu den Pickit 3 und> dann alles in C programmieren.
Ich sage Dir, warum ich den noch nie benutzt habe: Keine einzige meiner
privaten Basteleien hatte bislang einen Controller mit 20 Pins oder
mehr. Die meisten sind 8-Beiner, viele haben 14 Pins, selten mal 18.
Warum sollte ich mich mit einer Controllerfamilie beschäftigen, deren
Gehäuse immer eine Nummer zu groß für meine Applikationen sind?
> Ich wollte auch schon mal jemanden vorschlagen, einen modernen> PIC12F1xxx statt 12F675 zu nehmen, der Mann hat dankend abgelehnt, weil> der Komparator beim 675er bessere Werte hatte. Un damit hatte er Recht!
Warum sollte der 12F675 einen besseren Comparator haben?
Fred R. schrieb:> Warum sollte der 12F675 einen besseren Comparator haben?
Den Aufschluß gibt das Datenblatt Table COMPARATOR SPECIFICATIONS. Wenn
man die Werte des PIC12F675 mit z.B. PIC12F1840 oder PIC12F15712
vergleicht, dann sind beim 675er tatsächlich kleinere Werte für Response
Time und Input Offset Voltage. Wobei beim 675 die Tabelle deutlich
kleiner ist und einige Werte mit "parameters are characterized but not
tested" markiert sind, was auch immer das bedeuten mag.
Ohne Zweifel werden 8bit-Controller in 100 Jahren nicht tot sein!
Ich habe gerade 2 Projekte (Toaster-Controller und Multi-Timer) in C am
laufen mit 6pin pic10lf322 and attiny10 beide 0.5KWorte mit 64 bzw. 32
Byte RAM.
Unglaublich was schon mit diesen begrenzten Resourcen möglich ist. Aber
gerade auch wegen der On-Chip Peripherie.
Ich habe von pc10xx-pic24xx, attiny/atmega, arm cortex 3/4 und espxx
alles in den Händen und das reicht mir sicher bis zum Ableben.
Die Herausforderungen sind doch "The Art of Programming", die On-Chip HW
besser zuverstehen und einzusetzen und die Suche nach einer guten Idee
die das Problem clever löst.
Weniger löten ist ja auch viel gesünder - macht aber trotzdem immer noch
Spaß!
mt
p.s. Ich verliere regelmäßig den Überblick, bei den vielen Details und
Bits und ...
Apollo M. schrieb:> p.s. Ich verliere regelmäßig den Überblick, bei den vielen Details und> Bits und ...
Ich verliere beim Assembler-Programmieren auch immer den Überblick, wenn
der CPU-Kern mehr als nur ein Arbeitsregister hat... :D
Witkatz :. schrieb:> Wobei beim 675 die Tabelle deutlich> kleiner ist und einige Werte mit "parameters are characterized but not> tested" markiert sind, was auch immer das bedeuten mag.
Es ging damals wohl um die Offset-Spannung, und da sind max. +/-60mV
gegen +/-10mV doch schon ein deutlicher Unterschied.
Wie man auf meiner HP sieht, verwende ich am liebsten die pic12f1571 /
72.
Da wird der Offset mit typisch 7.5 mV angegeben.
Ausserdem kann man ihn feingranularer über die VREF / DAC Kombination
einstellen.
> mit 6pin pic10lf322
Das ist Falschgeiz.
Ausser Mann will vielleicht einem Matchbox Car einen Blinker verpassen.
Da ich gern fuer Projekte das Zeug am Lager hab, muesste ich sowas
erst bestellen. Da bleib ich doch lieber bei DIP-8 oder SOP-8.
+++ schrieb:> Das ist Falschgeiz.>> Ausser Mann will vielleicht einem Matchbox Car einen Blinker verpassen.
Nee, das Teil ist genial!
Weil ...
- super klein
- mit NCO und CLC kann man z.b. lineare PWM zur Lüftersteuerung bauen
oder linearen VCO oder ...
- Zeitsteurung mit Touch UI
- Toastersteuerung mit allem Pipapo was Toaster ab 100€ drauf haben
Genau so genial Atiny10, weil auch super klein!
Letzter Einsatz dieser Zauberlehrlinge war in meinen DECT Telefon, um
auf "long-press" einer Taste ein Eingabemakro abzufahren, damit die DECT
Station gewechselt wird und ich nicht in 4 Untermenues 7-mal die
Tastature quälen muss. Weil die Dinger so schön klein sind paßt das
direkt auf die Tastaturmatrix und fertig!
Oder für ein geliebtes Transistorradio oder ein altes Multimeter eine
auto power-off Funktion mit power-on via Touch ...
King ist hier das Package sot23-6, daher die zwei Riesen bekommen von
mir eine klare Empfehlung!
mt
> command not found: pic-gcc
Mit dem XC8 vermisse ich den nicht wirklich.
Zur Not hab ich auch noch nen alten IAR.
Die wirklich interessanten Dinge tut Mann auf den
kleinen Dingern eh in Assembler.
> Weil die Dinger so schön klein sind paßt das> direkt auf die Tastaturmatrix und fertig!
Nen SO-8 haett auch gepasst!
GARANTIERT!
Ich hab meine DECTs sogar von 3x AAA auf 3x AA umgebaut.
Das hat zum Schluss auch gepasst!
+++ schrieb:> Die wirklich interessanten Dinge tut Mann auf den> kleinen Dingern eh in Assembler.
Ich mache auch für diese Kleingeister alles in C, der Compiler optimiert
im Pro Mode recht ordentlich.
Man muss allerdings immer wiedermal clever rumprobieren, wie es der
Compiler noch optimaler hinbekommt. Also gehts erstmal um Funktion und
dann Size - gutes Training.
mt
p.s. Medizin für den Pro Mode on Request!
