Ich weiß es ist scho oft hier im Forum vorgekommen das der wunsch nach einem PIC - Forum geäußert wurde. Ich selbst bin ein µC Freak und arbeite auch immer noch mit pic´s (PIC18F452 <--- weil sie kostenlos sind) Ein PIC Forum wäre eine echte Bereicherung für www.mikrocontroller.net (sonst würde es ja auch AVR.net oder so heißen. Ich fände es schon wenn ihr eurerm Seitennamen gerecht werden würdet und auch noch den Pics in eurem Forum eine Sektion witmen würdet. Ansonsten macht weiter so PS.: Der Chat is immer wieder klasse und <verona> da wird man geholfen </verona > MFG Andreas Kaiser
:
Gesperrt durch Moderator
Ein PIC-Forum findest du hier: http://www.forenshop.net/cgi-bin/forenserver/foren/F_1402/cutecast.pl
Seit wann sind PIC18F452 kostenlos? Das halte ich für Unfung. Brauche ständig Mengen um 50 Stück und zahle > 13 EUR pro Stück. kopfschüttel
pic 18f452 sind kostenlos als freesample bei www.microchip.com zu bekommen schau einfach mal nach 50 stk bekommt du da aber net ich hab bis jetzt max 9 pro monat bekommen
@a-kaiser Endlich mal eine Begründung, die man auch kapieren kann. Ich habe mich schon ewig gefragt, warum relativ viele Leute was mit dem PIC machen, obwohl das Programmieren in Assembler alles andere als einfach und portabel ist im Vergleich zu z.B. 8051 oder AVR. Ich zahle da aber lieber 5 Euro und kann dann ordentlich programmieren, d.h. die Programme auch nach Jahren nachvollziehen und auch erweitern und problemlos auf beliebige andere Mitglieder der Familie portieren. Es ist ja auch gut zu sehen, die PIC-Programme sind oftmals aus einem Guß (Spaghetti-Kode), d.h. nicht modular und nur einfach Sachen. 8051 und AVR Programme sind da wesentlich komplexer d.h. sie können mehrere Aufgaben quasi gleichzeitig erledigen. Peter
Was du über das programmieren von Pic´s sagst kann ich nicht ganz teilen Die Programme können ebenso modular aufgebaut sein udn ich bin der Meinung das der Pic einem AVR in seiner Programmierbarkeit in nichts nachsteht Aber jeder sollte selbst wissen welchen chip er nimmet jedoch sind für Einsteiger Pics durch ihre Freesamples interessanter da oft die Kostenfrage eine rolle spielt
Ausserdem spielt der Assembler Code kaum eine Rolle mehr, wenn man einen Hochsprachen-Compiler verwendet. Da ist es viel leichter ein Programm übersichtlich und Modular aufzubauen. Naja - PIC und AVR - das ist mit AMD Athlon und Intel Pentium 4 bei den großen Prozzessoren zu vergleichen: Beide sind sehr sehr ähnlich und nehmen sich in Geschwindigkeit und Aussattung nicht viel. Die einen schwören auf AMD, die anderen auf Intel. Ist Geschmackssache und beide sind gut für alle möglichen Steuerungsaufgaben zu gebrauchen. MfG, Dominik S. Herwald
Sehr gutes Beispiel Dominik jedoch finde ich es schade das es noch "so wenig" über Pics hier auf der Seite gibt, da es wie schon gesagt dem Einsteiger eben einen sehr billigen einstieg ermöglicht MFG Andreas Kaiser
Warum sollte man nur um ein paar Euro zu sparen einen Prozessor mir einer völlig veralteten und haarsträubenden Architektur verwenden, für den es noch nicht einmal einen brauchbaren kostenlosen C-Compiler gibt?
Also C-compiler gibt es genug und was die Architektur betrifft glaub ich nicht das ein Pic18F452 einem AVR in etwas nachsteht ich kenn mich leider überhaupt nicht mit AVRs aus
> Also C-compiler gibt es genug Welchen z.B.? > und was die Architektur betrifft glaub ich nicht das ein Pic18F452 > einem AVR in etwas nachsteht Ich sag nur RAM-Banking, Hardwarestack...
C-compiler: Hi-tech ccs csc cc5x Das mit dem Bank switching is ok das is beim Pic echt ein problem
Für den SDCC gibts nen PIC Port - den hab ich selbst zwar noch nicht getestet, da ich derzeit viel in Pascal progge aber er soll funktionieren. Mehr auf http://www.gnupic.org/ bzw. auf http://sdcc.sourceforge.net/ Es gibt aber so gesehen wirklich nicht viele freeware C Compiler für PICs - Pascal und ähnliche Sprachen gibts da dann schon häufiger. Billig zu haben ist aber z.B. der C2C für 60 USD http://www.picant.com/c2c/c.html Das es da so viele kommerzielle Produkte gibt, liegt vermutlich daran, dass PICs sehr oft in industrieller Produktion eingesetzt werden wo Geld für Entwicklungstools meist keine Rolle spielt... MfG, Dominik S. Herwald
>Ich schrieb was von kostenlosen C-Compilern. Stimmt kostenlos sind die nicht Jedoch bietet HTSOFT einen kostenlosen PICC Lite C Compiler mit einigen einschränkungen an, die für einen Anfänger aber kaum von bedeutung sind. >Für den SDCC gibts nen PIC Port Das ist auch richtig jedoch nur für pic14 und Pic16 konnte es auch noch nicht testen da ich nur pic18 daheim habe MFG Andreas Kaiser
@Andreas, wenn ich deine Aussage zur völlig veralteten Technologie so lese????? Als Webmaster machst Du dich damit nur lächerlich. Schau dir mal die Datenblätter der 18FXXX-Reihe an. Steffen PS: Musste ich jetzt mal los werden, damit ist die Diskussion für mich abgeschlossen. Bringt eh nichts.
Hat man beim 18F... das Banking und den Hardwarestack endlich abgeschafft?
Nicht ganz, der Hardwarestack ist allerdings 32 Ebenen tief. Wem das nicht reicht, der kann sich über 3 FSR´s einen Softwarestack, vor allem für die Parameterübergabe zurechtbasteln. Je nachdem auf welches Register man bei der indirekten Addressierung zugreift wird das entsprechende FSR automatisch erhöht oder verringert. Man hat also im Prinzip 3 Stacks von denen man lesen kann und auf den man Werte mit nur einem Befehl abspeichern kann. Es gibt zwar immer noch RAM-Bänke zu je 256 Byte aber die meisten Register lassen sich direkt ansprechen. Um das Banking muss man sich da nicht mehr unbedingt den Kopf zerbrechen (wenn man ordentlich programmiert). Der direkt adressierbare lineare Programmspeicher beträgt übrigens 2MWord. Wie sieht das eigentlich beim Atmel aus? Im gegensatz zu der alten Serie ist der Kern sehr wohl für C optimiert. Schau dir wenn du Zeit hast mal eines der Datenblätter an. Die Nachteile der alten Serie gibt es nicht mehr. Vorteil der AVR ist, das sie mit bis zu 16MHz laufen. Die PICs mit max 10MHz (4 Taktzyklen = 1 Maschinenzyklus). Steffen
Nur damits keiner falsch versteht: Der interne Takt beträgt dann 10MHz - extern sinds 40 MHz. Aber dass sollte für die meisten Steuerungsaufgaben locker ausreichend sein ;) MfG, DSH
Ich bezweifle ja gar nicht dass es bei den neuen PICs mittlerweile Verbesserungen gibt. Worauf ich hinaus will: Es gibt für Anfänger einfach keinen Grund einen PIC zu verwenden. Der PIC ist voll von (teilweise kaschierten) Spezialitäten und Altlasten, die nur aus historischen Gründen beibehalten werden. Einen Hardwarestack oder Ram-Banking würde heutzutage niemand mehr im Traum für ein neues Prozessordesign in Erwägung ziehen. Muss man sich das als Anfänger also wirlich antun, nur um ein paar Euro zu sparen? Der AVR und besonders der MSP430 sind so einfach, logisch und leicht durchschaubar aufgebaut, dass man sie nach kurzer Zeit vollständig verstanden hat; außerdem bekommt man für beide Controllerfamilien sehr leistungsfähige C-Compiler kostenlos. Der linear adressierbare Programmspeicher ist beim AVR 8 MByte.
Na ja, da könnte man sich streiten, es würde aber eh nichts dabei herauskommen. Für den Hobbybastler ist der größte Vorteil des AVR, das es jede Menge kostenlose Tools wie C-Compiler etc. gibt. Da stimmme ich dir voll zu. Das RAM-Banking bei den 18Fxxx ist im Prinzip auch nur um mit einem 1-Word Befehl auf bestimmte Register zugreifen zu können. Es gibt aber auch zwei-Word Befehle, mit dehnen ich auch linear auf den kompletten Speicher zugreifen kann. In der Hinsicht kann das Banking (ist ja eh nur der High-Teil der RAM-Adresse) auch Vorteile, da ich unter Umständen Programmspeicher sparen kann. Steffen
Hallo, das PIC Mikrocontroller Forum ist umgezogen. Das neue Forum hat die Adresse: http://www.fernando-heitor.de/picforum/ Gruß Fernando Heitor
@a-kaiser: Der HTSOFT-Free-Compiler ist aber nicht für den PIC18, oder habe ich da was falsch verstanden? Ich würde gerne den 18F248 mit CAN einsetzen, das MPLAB habe ich noch von einem frühreren Projekt, aber ich möchte C verwenden, weil ich a) portablel bleiben will und b) noch Gänsehaut vom PIC16 Assembler habe. Taugt die Microchip-Compiler Demoversion für die PIC18-Serie etwas? Viele Grüße, Stefan
Also ich hab bis jetzt nur positive Erfahrung mit der Demoversion gemach. Anschauen lohnt sich auf jeden fall
Bin zwar nicht a-kaiser, antworte aber trotzdem. Die Demoversion ist zunächst mal nicht eingeschränkt. Nach 60 Tagen jedoch werden die Optimierungen abgeschaltet und der erweiterte Befehlssatz der PIC18 wird nicht mehr unterstützt. Compilieren ist jedoch noch möglich. Dieses Problem lässt sich übrigens sehr einfach umgehen. Du mußt den Compiler zu 100% (!!!) deinstallieren, eine Neuinstallation verschafft dir dann weitere 60 Tage. Thorsten
Ist das jetzt der HTSOFT-Compiler oder der Compiler von Microchip? PIC18C? weil den kann ich auf der Homepage von microchip als Demo nämlich nicht finden... hilfe Springer
so hab ihn jetz schon aber weiß nicht den befehlssatz und wie ich den pic in C programmieren kann! gibts bei der C18-software keine grafische Oberfläche??? Springer
Der C18 integriert sich sehr schön in MPLAB. Dokumentation zum Compiler gibts auch bei www.microchip.com.
Ich finde es auch sehr schade das hier fast nichts über PICs( oder auch andere ) steht. Ich selbst bastle etwas mit den Atmel dingern herum (AT89C52,AT89Cx051,ATtiny12,..). und ein freund von mir bastelt immer mit den PICs herum. und dadurch wir jetzt öfters zusammen am keyboard herumgebastelt haben, habe ich auch interesse an den PICs bekommen. Grund: 1. Sie sind billiger ;-) ( Samples; denn bei atmel die sample bestellung geht glaube ich nur für firmen oder etwa nicht?) 2. Sind sie robuster ;-) ( wir haben mal aus versehen 12V anstatt 5V an einem eingang angelegt. das einzige was war ist, dass der eingang defekt war, mehr nicht. bei solchen fehlern würden die atmel schon längst komplett defekt sein. ich mein ... ok .. ist schon ein fataler fehler.. aber sowas kann passieren.. und nur weil 1 Eingang ( von 23) defekt ist, ist das bauteil doch nicht ganz fürn arsch oder?) aber ansonst finde ich das forum sehr gut und surfe auch gerne darauf herum mfg
@Schoaschi "2. Sind sie robuster ;-) ( wir haben mal aus versehen 12V anstatt 5V an einem eingang angelegt. das einzige was war ist, dass der eingang defekt war, mehr nicht. bei solchen fehlern würden die atmel schon längst komplett defekt sein." Hast Du es ausprobiert ? Nein !!! Mir ist nämlich genau das gleiche passiert (12V an IO-Pin) mit genau dem gleichen Resultat (Pin tot, sonst nichts, auch keine erhöhte Stromaufnahme). Der Chip war aber ein Atmel AT89C51 ! Er tut noch mit den restlichen 31 Pins klaglos seine Dienste. Zum Glück wars ja kein Pin, der zum Flashen benötigt wird. Also bitte nicht leichtfertig falsche Vermutungen äußern. Peter
"1. Sie sind billiger ;-) ( Samples; denn bei atmel die sample bestellung geht glaube ich nur für firmen oder etwa nicht?)" Wenn jemandem einer abgeht, nur weil er was umsonst schnorren kann, dann von mir aus. Aber wenn man mal die Gesamtkosten eines Gerätes in Betracht zieht, dann sind die 1..3 Euronen für den (Atmel-) µC doch nur Pinats. Früher, wo man für nen P87C51 mit Fenster noch 80,-DM hinblättern mußte, war das freilich was ganz anderes, aber das ist ja nun auch schon über 10 Jahre her. Also immer schön auf dem Teppich bleiben. Peter
Autor: Steffen - sttagmx.de Datum: 21.02.2004 17:43 "Das RAM-Banking bei den 18Fxxx ist im Prinzip auch nur um mit einem 1-Word Befehl auf bestimmte Register zugreifen zu können. Es gibt aber auch zwei-Word Befehle, mit dehnen ich auch linear auf den kompletten Speicher zugreifen kann. In der Hinsicht kann das Banking (ist ja eh nur der High-Teil der RAM-Adresse) auch Vorteile, da ich unter Umständen Programmspeicher sparen kann. Steffen" Richtig Steffen! Diese Möglichkeit gibt es in noch größerem Umfang auf den HC11 Derivaten. Der HC11 hat einen zeitgeschützten Befehl (bei Progst.) mit dem seine Registerbank verschoben werden kann. Dadurch werden alle Register nur noch mit 8 BIt Adressen angesprochen und SEHR viel Progsp. gespart. Trotzdem haben alle Compiler die ich kenne diesen Befehl nicht genutzt, sodaß ich auch komplexe Programme in Assembler geschrieben habe weil ich sonst das Prog. nicht in den Speicher (68HC811E2 2KB) bekommen hätte. Einen Controller exellent zu nutzen ist NICHT in erster Linie seine Architektur, sondern wie er einem selbst liegt und wie man dann auch entsprechend damit umgehen kann. Vom HC11 CISC 52 auf PIC erweitern war natürlich erstmal schwierig, aber nach einiger Zeit Gewöhnung läuft es (für sein Einsatzgebiet) hervorragend. Die exellenten Verzweigungsmöglichkeiten des HC11 vermisse ich allerdings immer noch. MfG Manfred Glahe
interessante diskusion: ich selbst habe vor 9 jahren mit den ersten PICs angefangen... es war sogar mein einstieg in die mikrocontroller technik... damals war ich begeistert... 33 befehle, keine interrupts(die damals noch nicht ganz verstand) und ich habe einige projekte realisiert, die ich teilweise heute noch pflege... in assembler wohlgemerkt(da weiter oben der pic-assembler-code als kryptisch dargestellt wurde) ->das liegt am programmierer was er daraus macht... 5 jahre gab es nichts anderes für mich als PICs... bis ich weg von der (wie es microchip auch selbst nennt) pseudo-RISC-architectur... (4 takt = 1 systemtakt) auch die bankingstruktur ging mir echt auf den seier... und der AKKU :-P, ganz nach z80-manier also kam ein stk an den mann... es war liebe auf den ersten blick :-) die avr's waren damals einfach eine nuanze schneller... hatten eine reine architektur, und ordentliche befehle... ein einfach besser durchdachtes konzept (und das aus europa ;-) ), und konzipiert auf hochsprachen-fähigkeit... selbst schnellere programme liessen sich schreiben... dadurch das man bei 130 avr-befehlen 1befehl benötigte als man mit 33 pic-befehlen mit 3 anweisungen umschreiben musste, und das evtl. noch in einer schleife... eindeutiges todesurteil für pics, wenn man wie ich meist sehr zeitkritische anwendungen codiert... grundsätzlich will ich die avr's nicht mehr missen, und ich selbst favorisiere das "look and feel" der avr-familie... grundsätzlich sollte man nicht die ansicht vertreten "die benutzung eines bestimmten controllers wäre UNCOOL", viel eher sollte man berücksichtigen, welcher controller/welches werkzeug für die lösung eines problems am geeignetsten ist... dann zählt es nur noch, so viele verschiedene "controllerplattformen" zu beherrschen um wirklich vernünftig urteilen zu können, denn dann wird unterschieden nach preis und peripherie... ..und nicht die verliebtheit in eine spezielle familie kommt zum tragen... und nicht auf einen controller verharren, weil man ein FREIBIERGESICHT durch die welt trägt... man bekommt nämlich auf dem sample-weg auch avr's für umme :-P
@ Manfred Glahe: Auch ich habe lange Zeit mit dem HC11 verbracht und bin noch heute überzeugt von dessen geradliniger, logischer und (relativ) unkomplizierten Struktur. Später habe ich (ausbildungsbedingt) erst den Intel 8085, dann den Micrchip PIC 16F877 und schließlich den Infineon C515 kennengelernt. Angesichts meiner Erfahrungen mit dem HC11 konnte ich nie richtig verstehen, warum PIC und auch 8051 so verzwickte Speichermodelle haben müssen. RAM-Banking, Registerbänke, bitadressierbare Bereiche, etc. - das alles brauche ich beim HC11 nicht! Trotzdem muss ich all denen hier Recht geben, die empfehlen, sich nicht auf eine Architektur festzulegen: Im industriellen Umfeld spielen Faktoren wie Verfügbarkeit, Temperaturbereich, usw. oft eine größere Rolle als Preis und Programmers Model. Das Forum hier finde ich spitze, ich schaue sehr gerne bei euch rein, obwohl ich vermute, dass nicht alle der deutschen Sprache mächtig sind ;-)
> Das Forum hier finde ich spitze, ich schaue sehr gerne bei euch > rein, obwohl ich vermute, dass nicht alle der deutschen Sprache > mächtig sind Was soll DER Spruch jetzt? Hier ist ja nicht www.germanisten-unter-sich.net/forum :)
Hallo Leute, ich hab ein Problem mit meiner SPI-Schnittstelle: Meine Aufgabe ist es, die Daten, die von einer SPI-Schnittstelle gesendet werden mit dem Microcontroller PIC 16F873 einzulesen. Dabei verwende ich die hardwarmäßige SPI-Schnittstelle des Controllers. Dieser arbeitet mit dem externen Takt und somit als Slave. Zum Testen habe ich die Takteingangsleitung des PIC an einen entprellten Taster angeschlossen, um im Debugmodus den Takt selbst erzeugen zu können. Leider funktioniert das Ganze nicht richtig. Nur ab und zu wird in den Empfangsbuffer etwas reingeschrieben. Die Register für den SPI-Betrieb habe ich folgendermaßen konfiguriert: SSPSTAT = 0100 0000 (clock edge select = steigende Flanke) SSPCON = 0010 0100 (enables serial port;SPI slave mode;clock=SCK-PIN) Die Konfiguration müsste so eigentlich stimmen. Für eure Hilfe wäre ich sehr dankbar. Gruß, Markus
@Markus Rehn: So wie sich das für mich anhört, hast du ein Problem mit dem Slave Select Pin. Du hast SS control enabled, was dir bei dieser config auch nicht erspart bleibt, aber hast du das SS-Pin auch auf Low, wenn du Daten überträgst? Aber am besten du schickst mal ein bisschen Source... Grüße, Springer
Angehängte Dateien:
Hallo Klemens, (hab dir das auch per E-Mail gesendet!) Der Tipp mit dem SS contol enable war nicht schlecht. Tatsächlich hatte ich CKE=1 gesetzt, was soviel bedeutet wie, dass die SS-Leitung (PIN RA5 beim 16F873) benötigt wird und auf low gezogen werden muss. Nun hab ich aber nochmals nachgelesen und festgestellt, dass ich diese Leitung gar nicht brauche, wenn ich das CKE=0 setze und dafür im SSPCON-Register die Bits SSPM3...SSPM0 wie folgt setzte: 0101. Somit ist "SS pin control disabled". Also kommt es jetzt theoretisch nur noch auf den externen Clock an, um die Daten in das SSPSR-Register bzw. in das SSPBUF-Register zu bekommen und von dort aus weiterzuverarbeiten. Eigentlich müsste mit jedem empfangenen Byte das SSPIF-Bit im PIR1-Register gesetzt werden, also dann, wenn ich den Taster 8 mal gedrückt habe. Wenn der Buffer (SSPBUF) voll ist (FF), erscheint es aber schon nach jedem Takt. Das eigenartige ist auch, dass der Buffer (SSPBUF) wieder von selbst auf FF gesetzt wird, wenn ich ihn (im Watchfenster) lösche . Den Taster den ich zum Simulieren des Taktes verwendet habe, habe ich mit einem Differenzierglied entprellt, was auf dem Oszilloskop auch gut zu sehen ist. Ab und zu wird das BF-Bit (Buffer full) des SSPSTAT-Registers gesetzt. Gleich danach erlischt es dann wieder und es wird das SSPIF-Bit im PIR1-Register gesetzt, welches gleich danach auch wieder erlischt. Um ehrlich zu sein, sieht das Ganze so aus als würde es bereits funktionieren, leider versteh ich es noch nicht richtig. Wird der Buffer (SSPBUF) mit jedem neuen Bit geladen, oder geschieht das im Register SSPSR, welches dann erst das ganze Byte in den Buffer läd? Ich hab im Anhang noch ein Bild von der MPLAB-Oberfläche, mit der ich programmiere. Dort kann man die Register im Watch-Fenster erkennen. O.k. soweit mal zu den Erklärungen. Unten hab ich dann noch den Source eingefügt. Gruß, Markus PS: Danke für deine Hilfe! ASM-Source ab hier: ; PIC-Typ : PIC16F73A-I/SP Gehäuse : SP (PDIP) = 28 poliges DIL-Gehäuse ; Taktfrequenz : 20 MHz Oszillator : 20 MHz-Resonator ; TMR0 Prescaler: - Watchdog : Off ; TMR1 Prescaler :- ; TMR2 Prescaler :- ; ;*********************************************************************** ***************************************** ; ***************** ; Pinbelegungen ; ***************** ; ; Pin | Name | I/O | Funktion ; ; PortA | RA0/AN0 | I | --- ; | RA1/AN1 | I | --- ; | RA2/AN2 | I | --- ; | RA3/AN3 | I | --- ; | RA4 | I | --- ; | RA5/AN4 | I | --- ; | | | ; PortB | RB0 | I | --- ; | RB1 | I | --- ; | RB2 | I | --- ; | RB3 | I | --- ; | RB4 | I | --- ; | RB5 | I | --- ; | RB6 | I | Programmierschnittstelle ; | RB7 | I | Programmierschnittstelle ; | | | ; PortC | RC0 | 0 | --- ; | RC1 | 0 | --- ; | RC2 | 0 | --- ; | RC3/SCK | I | Clock-Eingang der SPI-Schnittstelle (enprellter Taster um den Takt zu simulieren ; | RC4/SDI | I | SPI: Seriel Data In; mal gegen Masse, mal gegen +5V gelegt, um Daten zu simulieren ; | RC5/SDO | 0 | SPI: Seriel Data Out; nicht angeschlossen (floatet) ; | RC6 | 0 | --- ; | RC7 | 0 | --- ; ; I = Input = Defaulteinstellung, 0 = Output ;*********************************************************************** ***************************************** ;************************************************************** ; benötigte Include-Files ;************************************************************** #include <P16f873a.INC> ; hiermit greift das MPLAB auf die Datei "P16f873a.INC" im MPLAB-Verzeichnisorder zu! ; Werden dort Änderungen vorgenommen, gelten diese in ALLEN Projekten! ;************************************************************** ; Konfiguration ;************************************************************** ; (siehe Datenblatt des 16F873 S.119) ; bis 4 MHz: Power on Timer, kein Watchdog, XT-Oscillator ; __CONFIG _PWRTE_ON & _WDT_OFF & _XT_OSC ; ; ab 4 MHz: Power on Timer, kein Watchdog, HS-Oscillator __CONFIG _PWRTE_ON & _WDT_OFF & _HS_OSC ;************************************************************** ; Variablendeklaration (Speicheradresse vergeben) ;************************************************************** zaehler equ 0x21 ; Speicherstelle des Zählers ;************************************************************** ; Einsprungpunkt beim Start/Reset definieren mit "org" ;************************************************************** org 0x0000 ; Einsprungpunkt/Programmstart bei 00h nop ; NOP-Befehle sind hier erforderlich nop goto MAIN ; Sprung zum Hauptprogramm (UPs sollen vor dem HP stehen!) ;************************************************************** ; Initalisierung ;************************************************************** INIT: ; Labels = Sprungmarken - immer GROß schreiben, zum Unterscheiden!!! ; Speicherbank 1 auswählen clrf PORTC ; PORT C vor Konfiguration löschen! (ist sicherer vor allem bei kritischen Anwendungen) bsf STATUS, RP0 ; umschalten auf Speicherbank 1 (nach Reset ist normalerweise immer Speicherbank 0 aktiv) movlw B'00011000' ; Konstante ins Arbeitsregister laden Alle Pins des PORT C auf Ausgang stellen (für diese Anwendung würde auch schon RC6 ausreichen) movwf TRISC ; Konfigurationsregister für Port C beschreiben movlw B'11111111' ; Konfiguration für "Input" laden movwf TRISA ; alle Pins des Port A als "Input" schalten bcf ADCON1, PCFG3 ; Bit3 im ADCON1-Register löschen (= PORTA auf digital I/0 konfigurieren) bsf ADCON1, PCFG2 ; Bit2 im ADCON1-Register setzen (= PORTA auf digital I/0 konfigurieren) bsf ADCON1, PCFG1 ; Bit1 im ADCON1-Register setzen (= PORTA auf digital I/0 konfigurieren) ; SSPSTAT = 00XX XXXX ; bitweise Konfiguration der SPI-Schnittstelle, Achtung: Register liegt in Speicherbank 1 bcf SSPSTAT, SMP ; im SSPSTAT-Register das Bit SMP (sample bit=Abtastbit) löschen! (muss im Slavemode so sein, siehe Datasheet S.66) bcf SSPSTAT, CKE ; im SSPSTAT-Register das Bit CKE (clock edge select) löschen! bcf STATUS, RP0 ; auf Speicherbank 0 zurückschalten ; Hinweis: die nachfolgenden 2 Programmzeilen ersetzten die oben gezeigte Speicherbankumschaltung!...allerdings nur für TRISC! ; movlw B'00001000' ; I/O-Konfiguration für PORT C laden: TRISC<3>=Serial Clock, TRISC<4>=Serial Data Input=automatically controlled, TRISC<5>=Serial Data Output ; tris PORTC ; lädt den Wert vom Arbeisregister w in das TRIS-Register des PORT C - schaltet automatisch auf die richtige Speicherbank um! ; Speicherbank 0 gewählt: ; SSPCON = XX10 0101 ; bitweise Konfiguration der SPI-Schnittstelle (Register liegt in Speicherbank 0) bsf SSPCON, SSPEN ; im SSPCON-Register das Bit 5 setzen! (SSPEN = synchronous serial port enable bit) bcf SSPCON, CKP ; im SSPCON-Register das Bit 4 löschen!(CKP = clock polarity select bit) bcf SSPCON, SSPM3 ; SSPM3...SSPM0: 0100 = SPI Slave mode, clock=SCK-PIN, SS-PIN control disabled (S.67 in Datasheet) bsf SSPCON, SSPM2 ; bcf SSPCON, SSPM1 ; bsf SSPCON, SSPM0 ; return ; Rücksprung ins HP "MAIN", momentaner Wertes im Arbeitsregister bleibt unverändert ;********************************************************** ; Hauptprogramm ;********************************************************** MAIN: call INIT ; Aufruf des Unterprogramms "INIT" --> Initialisierung durchführen movlw 0x00 movwf zaehler ; Zähler löschen LOOP: ; Endlosschleife: während des Durchlaufs im Debugmodus müssten die jeweiligen Flags gesetzt werden ; Zähler um die Interrupflags zu zählen, die beim Eintreffen von Bits gesetzt werden: btfsc PIR1, SSPIF ; ist das SSPIF nicht gesetzt, wird der nächste Befehl übersprungen incf zaehler, f ; Zähler incrementieren, wenn SSPIF (synchronous serial port interrup flag) gesetzt wird ; Flag wird beim Eintreffen eines Bits gesetzt (sollte zumindest so sein...ist bei mir aber nicht der Fall!) ; ...für später: ; movf SSPBUF, w ; schreibt den Inhalt den Empfangs-Buffers in das Arbeitsregister ; btfsc SSPSTAT, BF ; gleiche Testsubtraktion nochmals; BF = Buffer Flag (Empfangs-Buffer ist voll) ; movwf PORTB ; empfangenes Byte auf PORTB schreiben btfsc PIR1, SSPIF ; synchronous serial port interruptflag bcf PIR1, SSPIF ; Interruptflag löschen goto LOOP END
Hi Markus! Grundsätzlich solltest du das TRISC Register konfigurieren, also SCK auf JEDEN FALL als Input deklarieren und auch SDI. Am besten du konfigurierst das ganze TRISC. ZITIERT: "Eigentlich müsste mit jedem empfangenen Byte das SSPIF-Bit im PIR1-Register gesetzt werden, also dann, wenn ich den Taster 8 mal gedrückt habe. Wenn der Buffer (SSPBUF) voll ist (FF), erscheint es aber schon nach jedem Takt. Das eigenartige ist auch, dass der Buffer (SSPBUF) wieder von selbst auf FF gesetzt wird, wenn ich ihn (im Watchfenster) lösche. Um ehrlich zu sein, sieht das Ganze so aus als würde es bereits funktionieren, leider versteh ich es noch nicht richtig. Wird der Buffer (SSPBUF) mit jedem << neuen Bit geladen, oder geschieht das im Register SSPSR, welches dann erst das ganze Byte in den Buffer läd?" ENDE Das Bit das du benützen solltest ist SSPSTAT,BF und wird nach jedem empfangenen Byte gesetzt. Das Bit im PIR Register ist nur für Interruptroutinen. So wie das für mich aussieht, verwendest du aber die Polling Methode und da solltest du dann auch in solch einer Methode das Buffer - Full Bit pollen. ZITIERT: "Ich hab im Anhang noch ein Bild von der MPLAB-Oberfläche, mit der ich programmiere. Dort kann man die Register im Watch-Fenster erkennen." ENDE Verwendest du eine Entwicklungsumgebung von MPLAB wie z.B.: ICD 2? Weil sonst kannst du die Watch - Funktionen nämlich nicht benutzen. Also ich könnte mir den Quellcode so vorstellen (deiner verändert), in der Anlage.
Hallo Klemens, vielen Dank für Deine Mühe und dein File, das du mit drangehängt hast. Ja, ich verwende die ICD 2-Entwicklungsumgebung, mit dem ICD 2-Debugger. Die Dinge haben wir hier im Betrieb. Leider ist nächste Woche mein PS zu Ende. Deshalb würde ich mir noch gerne ein Programmiergerät bauen, damit ich zu Hause weitere Programme schreiben kann. Auf der Seite www.sprut.de hab ich so ein Bauplan gefunden. Hab allerdings noch keine Zeit gehabt, das genauer durchzulesen. Aber wenn ich dich richtig verstehe, würde dann die Debugfunktion mit dem Watchfenster nicht funktionieren!? Gruß, Markus
Kein Problem, für so was ist ein Forum schließlich da... :-) Der ICD-2 wurde von Microchip geschaffen um live zu debuggen.. Mit einem normalen Brenner (sprut.de) kann man jedoch nur brennen! Aber die Seite www.sprut.de ist für PIC-Anfänger wie geschaffen. Wenn du dich dort umsiehst und den Brenner baust, der ausgezeichnet funktioniert (auch ich habe damit angefangen), dann wird es dir nicht schwer fallen dich bald besser auszukennen. Sprut selber ist auch selber sehr hilfsbereit bei Problemen... Also, gutes Gelingen, Grüße, Springer P.S.: Funktioniert das Teil mit SPI schon?
Habs hingekriegt! Funktioniert jetzt! Herzlichen Dank nochmals für deine Hilfe. Gruß, Markus
Hey Leute, ich muss hier eine Projektarbeit fertig stellen und mir fällt einfach der name von dem verfahren ein bei dem die eingänge in jedem takt zyklus mit überprüft werden, quasi das gegenteil einer intteruptfunktion, könnte mir da vielleicht jemand auf die sprünge helfen
Horst wrote: > Hey Leute, ich muss hier eine Projektarbeit fertig stellen und mir fällt > einfach der name von dem verfahren ein bei dem die eingänge in jedem > takt zyklus mit überprüft werden, quasi das gegenteil einer > intteruptfunktion, könnte mir da vielleicht jemand auf die sprünge > helfen Du erwartest doch jetzt nicht etwa, dass Dir jemand schreibt, dass das Polling heißen könnte, oder? ...
Kennt jemand eine gute Seite mit tutorials, codebeispielen usw für den C18? Bin gerade dabei mich mit dem auseinander zu setzen, bei den Headern des C18 stört es mich, dass die Registerbits nicht als globale variablen sondern nur als Union verfügbar sind, ist immer ziemlich doof den Registernamen zB als TRISCbits zu schreiben und auf jedes bit einzeln zugreifen zu müssen... Natürlich könnt ich mir die header jetzt selbst anpassen... aber naja :-)
juppi wrote: > hallo > ein wort sagt mehr wie ganze sätze > > Mfg Soll ich mir jetzt abgewöhnen, im ganzen Satz zu antworten?? ...
ja klar! und die Groß und Kleinschreibung sollst du auch vernachlässigen... Entschuldigung, ich habe sie mir leider noch nicht abgewöhnt ;) Gruss Stefan
Thread beobachten
Seitenaufteilung abschalten