www.mikrocontroller.net

Forum: www.mikrocontroller.net pic das forum


Autor: a-kaiser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Ralf L. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ganz einfach: hier gibt es kein AVR-Forum, deshalb wird es auch kein
PIC-Forum geben.

Autor: Mathias Märker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: a-kaiser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: a-kaiser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dominik S. Herwald (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: a-kaiser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: a-kaiser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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...

Autor: a-kaiser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C-compiler:
Hi-tech
ccs
csc
cc5x

Das mit dem Bank switching is ok das is beim Pic echt ein problem

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich schrieb was von kostenlosen C-Compilern.

Autor: Dominik S. Herwald (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: a-kaiser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Steffen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat man beim 18F... das Banking und den Hardwarestack endlich
abgeschafft?

Autor: Steffen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dominik S. Herwald (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Steffen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Fernando Heitor (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

das PIC Mikrocontroller Forum ist umgezogen.
Das neue Forum hat die Adresse:

http://www.fernando-heitor.de/picforum/

Gruß
Fernando Heitor

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: a-kaiser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich hab bis jetzt nur positive Erfahrung mit der Demoversion
gemach.

Anschauen lohnt sich auf jeden fall

Autor: Klemens Springer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@a-kaiser

Inwiefern ist denn die C-Demoversion für die 18Fs eingeschränkt?

Autor: Thorsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Klemens Springer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Klemens Springer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thorsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der C18 integriert sich sehr schön in MPLAB. Dokumentation zum Compiler
gibts auch bei www.microchip.com.

Autor: Schoaschi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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: Manfred Glahe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Philip Krause (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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
;-)

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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 :)

Autor: Markus Rehn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Klemens Springer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Markus Rehn (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Klemens Springer (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus Rehn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Klemens Springer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Markus Rehn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habs hingekriegt! Funktioniert jetzt! Herzlichen Dank nochmals für deine
Hilfe.

Gruß, Markus

Autor: Horst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

...

Autor: Ede (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
polling ?

gruß Ede

Autor: juppi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo
 ein wort sagt mehr wie ganze sätze

Mfg

Autor: Marius S. (lupin) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 
:-)

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
juppi wrote:
> hallo
>  ein wort sagt mehr wie ganze sätze
>
> Mfg

Soll ich mir jetzt abgewöhnen, im ganzen Satz zu antworten??

...

Autor: stefan b (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja klar! und die Groß und Kleinschreibung sollst du auch 
vernachlässigen...

Entschuldigung, ich habe sie mir leider noch nicht abgewöhnt ;)

Gruss
Stefan

Beitrag #2316279 wurde von einem Moderator gelöscht.
Dieser Beitrag ist gesperrt und kann nicht beantwortet werden.