• 19.04.2024, 13:17
  • Registrieren
  • Anmelden
  • Sie sind nicht angemeldet.

 

Lieber Besucher, herzlich willkommen bei: Aqua Computer Forum. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

Unterschiede PIC C und F Serie?

Donnerstag, 15. August 2013, 20:23

Hi,

ich habe da mal eine Frage. Wofür steht das C bzw. F bei PIC Controllern?
Ich habe nämlich 10 PIC16C55 und 5 PIC16F877A-I/P geschenkt bekommen ;-)



Liebe Grüße
Sascha :)

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Sappibaer« (15. August 2013, 20:33)

Out of Style, but it's Retro!

Donnerstag, 15. August 2013, 20:53

Schau Dir doch einfach mal die Datenblätter an. Der Programmspeicher des C55 ist laut dieser Seite OTP, der andere hat Flash.
Nur mal als Beispiel.

Donnerstag, 15. August 2013, 21:26

Schau Dir doch einfach mal die Datenblätter an. Der Programmspeicher des C55 ist laut dieser Seite OTP, der andere hat Flash.
Nur mal als Beispiel.

Ich danke dir ;)

Das war auch eigentlich die haupt Info die ich benötigte, nur ich war zu doof es im Manual zu finden. :wacko: :D
Out of Style, but it's Retro!

Freitag, 16. August 2013, 11:27

Wie gesagt, nur ein Unterschied. Das sind komplett unterschiedliche Kontroller. Was da alles unterschiedlich ist, mußt Du den Datenblättern entnehmen. Zur Nomenklatur der PIC-Namen kann ich Dir leider nichts sagen - ich benutze Atmel-Controller.

(Derzeit quetsche ich versuchsweise einen SoftwareUART-Empfang (mit 8fach Oversampling) und HardwarePWM in einen ATtiny10 (SOT23))

Achso, gerüchteweise wurden manchmal bei solchen OTP-Speichern UV-erasable PROMs (UV-EPROM) eingesetzt - manchmal auch ohne Löschfenster. Wenn Du die also nicht programmiert bekommst, kannste ja mal einen aufdremeln.

Aber eigentlich sind das Dinos...

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »LotadaC« (16. August 2013, 11:31)

Freitag, 16. August 2013, 19:00

Wie gesagt, nur ein Unterschied. Das sind komplett unterschiedliche Kontroller. Was da alles unterschiedlich ist, mußt Du den Datenblättern entnehmen. Zur Nomenklatur der PIC-Namen kann ich Dir leider nichts sagen - ich benutze Atmel-Controller.

(Derzeit quetsche ich versuchsweise einen SoftwareUART-Empfang (mit 8fach Oversampling) und HardwarePWM in einen ATtiny10 (SOT23))

Achso, gerüchteweise wurden manchmal bei solchen OTP-Speichern UV-erasable PROMs (UV-EPROM) eingesetzt - manchmal auch ohne Löschfenster. Wenn Du die also nicht programmiert bekommst, kannste ja mal einen aufdremeln.

Aber eigentlich sind das Dinos...

Aufdremeln lohnt sich nicht ;D

Die OTPs sind schon mal beschrieben worden und somit unbrauchbar ;-)

Aber die anderen leg ich mir einfach mal zur Seite. Einem geschenkten Gaul, schaut man nicht ins Maul :D.

Mei derzeitiges Projekt ist die Ansteuerung eines Steppermotors mit veränderbarer Drehzahl und Pause Taste. Controller ist nen Atmega8 und ich mach mich gerade an den Code ran ;)
Out of Style, but it's Retro!

Freitag, 16. August 2013, 20:34

Mit 'nem halbwegs intelligenten Treiber-IC dazwischen (zB L6208, oder zumindest die klassische L297/L298-Kombination),, oder steuerst Du entsprechende TreiberFETs direkt an?
Das erste ist ja simpel: Richtung mit einem Pin festlegen, Geschwindigkeit über 'nen Timer mit 'nem OC-Pin. Müßte jetzt erst ins DB-schauen, beim Mega88 hätte ich's im Kopf - egal. Timer am besten im CTC-Mode (TOP=ICR? oder OCR?A) - den (anderen) OC-Kanal auf Toggeln bei Überlauf gesetzt. Jetzt kannst Du die Frequenz im groben mit dem Prescaler festlegen, im feinen mit dem TOP-definierenden Register. Zum anhalten einfach den Prescaler auf 0.

Wenn Du das Komplett selbst direkt implementieren willst (also mit der stepping-state-machine) wirds etwas komplizierter. Letztendlich landet die StateMachine im SRAM, die generation der Takte prinzipiell wie oben, nur daß Du Dich jetzt in der ISR selbst um die FETs kümmern mußt. Wahrscheinlich kommt man auch hier mit 4 Beinchen aus (zB D7..D4), indem man vom Bein aus über 2 Dioden auf die Gates der beiden FETs (HighSide/LowSide) geht. Dann kann der Tristate-Pin beide FETs abschalten (zum Abschalten sind entsprechende PullUps/Downs an den Gates).
Die Bytes im SRAM enthalten in einem Nibble die Information für die PORT-Bits, im anderen Nibble die für die DDR-Bits.
In der Überlauf-ISR inkrmenierst Du einen Adresszeiger auf die Table (ggf zurücksetzen), und lädst den State in ein Rechenregister, Jetzt manipulierst Du dass DDR und PORT-Register entsprechend Deines State-Bytes (Achtung, die anderen Bits müssen über eine RMF-Operation gesichert werden, außerdem müssen alle Pins vor der Änderung Tristate werden der interne Pullup (DDR=0, Port=1) darf den FET nicht durchschalten können (gegen den externen Pulldown), dann sollte das etwa so gehen: Datenrichtungsregister laden, Bits für die FETs löschen (ANDI), zurückschreiben, PortRegister laden, dort entsprechende Bits umschreiben und zurückschreiben, jetzt in der Kopie des Datenrichtungsregisters die Bits aus dem State ergänzen, und es ins DDR zurückschreiben.
Alternativ könnte man auch überlegen, ob sich das schneller und codesparender mittels direkten Bitinstruktionen umsetzen läßt.
Oder man vertauscht erstmal die Nibbles (SWAP) vom DDR bzw PORT, und schiebt(rotiert) die Bits aus dem State (über das Carry) in das DDR bzw Port. Auch bei diesen beiden Alternativen darf der Tristate-Zwischenschritt natürlich nicht fehlen.

Aber ich sehe schon kommen, daß Du a eh nicht in Assembler umsetzen willst...
Trotzdem viel Erfolg.

Freitag, 16. August 2013, 21:29

Du wirst es nicht glauben, aber Assembler steht in der engeren Auswahl ;)
Out of Style, but it's Retro!

Ähnliche Themen