Hallo, in meinem aktuellen Programm auf dem 16F84A ist es notwendig, während des Betriebs eine Speicherzelle auszulesen und sie so zu speichern, daß ich sie nachher mit dem Programmiergerät aus dem PIC auslesen kann. Dazu scheint mir der EEPROM geeignet. Im Datenblatt gibt es zwar ein Codebeispiel, was mir aber noch nicht ganz klar ist. Es gibt ja EEDATA, EEADR, EECON1 und 2. Die CONs sind wohl die Kontrollregister, nur sehe ich in dem Codebeispiel nirgends, daß EEDATA und EEADR benutzt wird. Man sollte doch wissen, wo man was hinschreibt. Hier das Beispiel: BSF STATUS, RP0 ; Bank 1 das ist klar BCF INTCON, GIE ; Disable INTs. das auch BSF EECON1, WREN ; Enable Write und das ebenfalls MOVLW 55h ; was soll das jetzt? Ist 55h der zu speichernde Wert? MOVWF EECON2 ; Write 55h MOVLW AAh ; MOVWF EECON2 ; Write AAh Würde damit der Wert 55AAh geschrieben, oder AA55h? und vor allem, an welche Adresse wird geschrieben? BSF EECON1,WR ; Set WR bit das ist wieder klar ; begin write BSF INTCON, GIE ; Enable INTs. und auch das Bitte um Erklärung T.
Du schreibst die Adresse und die Daten in das jeweilige Register EEDATA&EEADR. Um die Daten in die Adresse zu schreiben, muss eine Codefolge in das EECON2-Register geschrieben werden. Also übernimmt das EEPROM die Daten vom RAM-Register, wenn erst 55h(01010101) in EECON2 steht und danach AAh(10101010). Wenn dieser Wechsel von 55 auf AA kommt, beschreibt er den EEPROM. edit: Man kann es sich auch in etwa so vorstellen, als hätte man 16 Eingänge bei einem 16bit Speicher, die übernommen werden, wenn eine High-Flanke am Clockeingang kommt. Die 16 bit sind dein EEDATA und EEADR und der Clock geht von 0 (55h in EECON2) auf 1 (AAh in EECON2). Ich weiß nicht, ob das daruch klarer wird;)
Ich hab mir jetzt nochmal das DB angeguckt, da stehts doch ansich auch drinne: >>3.2 Writing to the EEPROM Data Memory >> >>To write an EEPROM data location, the user must first >>write the address to the EEADR register and the data >>to the EEDATA register. Then the user must follow a >>specific sequence to initiate the write for each byte. >>(Codebeispiel) >>The write will not initiate if the above sequence is not >>exactly followed (write 55h to EECON2, write AAh to >>EECON2, then set WR bit) for each byte. We strongly >>recommend that interrupts be disabled during this >>code segment. Wegen den Interrups weißt du ja bescheid. Abgesehen davon, wenn es darum geht, Daten vom µC auf den Rechner zu bekommen, dann könnte folgendes auch interessant sein: RS232, Parallel(Drucker-)Port, SD-Karte via SPI, USB. Zugegeben es wird nach hinten hin immer komplizierter von der Software und kann teils nicht mit dem 16f84 (übrigens ein Jahrzehnte-alter nichtskönner;) ) gemacht werden. Wollte es trotzdem mal erwähnt haben.
Stimmt, ich hatte die Stelle auch gefunden, ich fand's nur komisch, eine bestimmte Bitfolge zum Schreiben durchführen zu benutzen. Du hast natürlich recht, ich könnte auch eine RS232- oder USB-ausgabe machen, mein Board kanns, aber mit dem EEPROM denke ich ist es am einfachsten. Ich brauche lediglich diesen einen Wert aus der Programmausführung. Zum 16F84: wenn ich das Programm zufriedenstellend zum Laufen bekommen habe, wird upgedated auf den 16f88 oder 16f887 T.
Thomas M. schrieb: > Zum 16F84: wenn ich das Programm zufriedenstellend zum Laufen bekommen > habe, wird upgedated auf den 16f88 oder 16f887 Gut^^ Ist halt n kleines Ding. Die neuen 16F1xxx bekommt man garnicht bei Reichelt, sehe ich grade. Bei Microchip kosten die aber gleich viel oder sind billiger als die "alten" PICs obwohl die mehr können. Naja. Wenn du dann den 16F887 hast und dich in C einarbeiten willst kannst du ja auch als nächst besseren Chip nen 18F nehmen. Ich bin keinesfalls ein 16F-hasser, doch da die Config bzw Peripherie ein bisschen anders ist, kannst du dich mit denen da schonmal eingewöhnen, wenn du später C auch ausnutzen willst, wie z.B. Ethernet oder USB (gibts bei <=16F nämlich nicht). Wenn du denn soweit gehen willst;)
Weiß nicht, ob ich C wirklich will. Das scheint etwas komplizierter zu sein. Der C-Compiler, der mit meinem Board(EasyPIC6) mitgliefert wurde, hat Einschränkungen, und die Vollversion ist schweineteuer. Außerdem hat wohl jeder C-Compiler für µController seine eigenen Befehle, wenn ich also einen Compiler kann, heißt das nicht, daß ich auch mit anderen klarkomme. Die Assembleranweisungen hingegen sind immer diesselben, und MPLAB IDE ist kostenlos :-) T.
Thomas M. schrieb: > Weiß nicht, ob ich C wirklich will. Bei USB und und Ethernet WILLST du das, glaub mir;) Abgesehen davon ist C SEHR viel angenehmer zu programmieren, was auch der Sinn von Hochsprachen ist;) Solange es nicht wirklich eng mit dem Programmspeicher wird, bleib ich auch bei C. Wenn der Speicher grade so nicht reicht, nehme ich eher einen größeren PIC. Selbst die kleinen 12F programmiere ich in C. Thomas M. schrieb: > Der C-Compiler, der mit meinem Board(EasyPIC6) mitgliefert wurde, > hat Einschränkungen, und die Vollversion ist schweineteuer. Die Einschränkung vom MPLAB C-Compiler C18 oder C30, sowie vom mikroC Compiler, den ich nehme, sind nur Optimierungseinschränkungen. Keine Zeitbegrenzung und mit der "gedrosselten" Optimierung kommt man gut klar. Thomas M. schrieb: > Außerdem hat > wohl jeder C-Compiler für µController seine eigenen Befehle, wenn ich > also einen Compiler kann, heißt das nicht, daß ich auch mit anderen > klarkomme. > Die Assembleranweisungen hingegen sind immer diesselben Andersrum wird n Schuh draus. C ist C, das ist eine Programmiersprache. Das einzige, was anders ist, sind die Hardware-bezogenen Funktionen und Variablen. Wenn es beim PIC z.B. ein OSCCON-Register gibt und beim AVR nicht bzw anders heißt. Genauso, wenn es beim PIC18F4550 ein PORTC gibt und beim PIC16F84 nicht;) Doch wenn man ein Lauflicht für einen PIC in C programmiert, das mit einem Taster in der Richtung geändert wird, kann man das nach Anpassung der "Hardware-Variablen" und µC-Config auch auf einem AVR laufen lassen. Wenn du ASM für PIC programmierst und dir dann mal ein ASM-Code für den AVR anguckst, stehste vorm Wald! ;) Du musst halt nur gucken, dass der C-Compiler für ein PIC ist. Denn wie gesagt, C ist zwar von sich aus gleich, der ASM-Code und Maschinencode sind es aber nicht.
Michael Skropski schrieb: > Die Einschränkung vom MPLAB C-Compiler C18 oder C30, sowie vom mikroC > Compiler, den ich nehme, sind nur Optimierungseinschränkungen. Keine > Zeitbegrenzung und mit der "gedrosselten" Optimierung kommt man gut > klar. Interessant! Ich habe nämlich den mikroC, und der ist beschränkt auf eine HEX-Größe von 2kB. Mittelprächtiger Witz! Aber kommen wir nochmal zu MPLAB-kompatiblem C-Compiler: welchen empfiehlst du mir? Ich finde MPLAB eigentlich ganz gut... T.
Thomas M. schrieb: > Interessant! Ich habe nämlich den mikroC, und der ist beschränkt auf > eine HEX-Größe von 2kB. Oh ich hab nochmal nachgeguckt.. die 5.0Version ist auf 4kB begrenzt. Thomas M. schrieb: > Aber kommen wir nochmal > zu MPLAB-kompatiblem C-Compiler: welchen empfiehlst du mir? Ich finde > MPLAB eigentlich ganz gut... den von Microchip direkt, ist der nicht direkt bei MPLab dabei?? Heißt C18 für 8bitµC, C30 für 16bit und C32 für 32bit. Da bin ich mir aber nicht sicher. Es gibt sie auf jedenfall. Einfach mal googlen
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.