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.
1 | call 0x3FF ;Kalibrierungswert holen |
2 | movwf OSCCAL ;Kalibrierung |
Lass das mal weg.
Doppelpost !!! Gestern noch als Christian Weber (Gast) Beitrag "Anfänger sucht Unterstützung beim Flashen PIC12F629 mit PICKit3" Heute als Rudolf Ratlos, Und morgen?
>Heute als Rudolf Ratlos, >Und morgen? Als Erich. Tja -so ist das, wenn man als Gast posten kann.
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
:
Bearbeitet durch User
Beitrag #5316231 wurde vom Autor gelöscht.
hi, zum spielen attached das simulator asm file sollte auch in hw lauffähig sein. mt
... und hier noch die version in c für xc8 compiler. 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!
:
Bearbeitet durch User
... 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.
:
Bearbeitet durch User
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
:
Bearbeitet durch User
... 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 ...
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
Beitrag #5318227 wurde vom Autor gelöscht.
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.
Fred R. schrieb: > pic12f1571 / > 72. > Da wird der Offset mit typisch 7.5 mV angegeben. Da siehst du es, bei PIC12F675 sind es typisch 5mV, max. 10mV.
> 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
:
Bearbeitet durch User
pic-gcc command not found: pic-gcc PIC sucks! >Genau so genial Atiny10, weil auch super klein! kann man nur nirgends kriegen für billich.
> 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!
Beitrag #5341496 wurde von einem Moderator gelöscht.
Beitrag #5345300 wurde von einem Moderator gelöscht.
Naja, das ASM file hat zwei Denkfehler. 1) _MCLRE_ON , dies heisst GPIO.3 ist nicht verfügbar. 2) GPIO.3 hat kein pull-up, dieser muss extern sein.
Beitrag #5345428 wurde von einem Moderator gelöscht.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.