Hi Georg
Ich würde dir einen PIC empfehlen !!
Ich habe auch mit PIC's angefangen und bin klasse in die Matertie
hereingekommmen. Der Assembler ist einiges einfacher, wie bei AVR. Nur
35 Befehle. AVR = über 100 Befehle.
Außerdem gibt es wenn du unbedingt USB willst den PIC 16C765 mit
integriertem USB. Aber eines muss dir bei USB im klaren sein.
1. es ist viel komplizierter und Aufwendiger als RS232 (USART),
(einziger
Vorteil Vcc=5V Rs232= +/- 12V)
1. Es benötigt auch gute DOS-Assembler oder C kentnisse, den Enpfänger
(Computer) zu kalibrieren und ein Programm zu schreiben, dass dann das
Zeig rüberlädt.
Aber mit PIC bist du auf jeden Fall gut beraten!
- PIC's sind billig
- Programmer kriegt man bei Ebay für'n paar Mark
- Die komplette Software ist kostenfrei (MPLAB, etc.)
> Der Assembler ist einiges einfacher, wie bei AVR. Nur> 35 Befehle. AVR = über 100 Befehle.
Lieber ein paar Befehle mehr, als sich bei einfachsten Dingen einen
abzubrechen.
> - PIC's sind billigAVRs noch billiger
> - Programmer kriegt man bei Ebay für'n paar Mark
Für AVRs hat die 5 Bauteile in der Bastelkiste, die Software gibts
gratis.
- Die komplette Software ist kostenfrei (MPLAB, etc.)
> Die für die Atmels kostet 10000000 Euro
BTW: auf welchen Beitrag wolltest du eigentlich antworten?
> 35 Befehle. AVR = über 100 Befehle.
Das ultimative Argument für MaxQ2000. Da gibt es nur einen einzigen
Befehl mit 2 Adressierungsarten. Also ganz leicht zu merken.
Im Handbuch davon. Nicht im Klartext, aber es geht eindeutig aus der
Befehlscodierung hervor. Das zugrunde liegende Prinzip geisterte schon
lang als running gag durch Rechnerarchitektur-Vorlesungen und -Foren,
aber Maxim hat tatsächlich damit Ernst gemacht.
Falls ein Browser mit dem Anhang Probleme hat: ist ein PNG.
"Typic"s Frage erinnert übrigens an ein Experiment in praktischer
Verhaltensforschung: Such dir eine möglichst hirnrissige These aus, geh
ins Lager der natürlichen Gegner dieser These und rufe sie laut aus. Wie
weit kannst du gehen, ohne dass Blut fliesst? ;-)
>Falls ein Browser mit dem Anhang Probleme hat: ist ein PNG.
Jetzt habe ich es auch herausgefunden.
>"Typic"s Frage erinnert übrigens an ein Experiment in praktischer>Verhaltensforschung: Such dir eine möglichst hirnrissige These aus, geh>ins Lager der natürlichen Gegner dieser These und rufe sie laut aus. Wie>weit kannst du gehen, ohne dass Blut fliesst? ;-)
Ja, das stimmt. Vor allem das Argument "PIC hat 35 Befehler, AVR xyz".
Ich habe am Anfang auch gedacht, meine Güte, was hat Atmel denn noch so
alles implementiert. Bis ich herausgefunden habe, dass z.B. für die
Abfrage jedes der einzelnen Bits im Statusregister ein eigener "Befehl"
zur Verfügung steht. SO kann man die Befehlszahl auch aufblähen. Die
PICs sind nicht schlecht, wenn nur nicht dieses blöde 'Banking' wäre...
hi Typic
darf ich fragen, wann du zum letzten mal dich mit den PICs auseinander
gesetzt hast? einem neuling einen C-typ vorschlagen, tzz tzz... mach mal
ne runde auf der homepage des herstellers und guck dir an, was es gibt
;) wie wär's z.b. mit den neueren aus der 18er reihe: gratis compiler,
SW, librarys, demos und und und... ps: hätte sogar auch welche mit USB
;) ...und wenn die leistung der 18er nicht reicht, einfach den code
behalten (mehr oder weniger) und für einen dsPIC compilieren, der die
3-4x leistung hat und erst noch 16bit breit ist ;)
ps: brenner kann man sich auch für PICs ab 5 Euros machen ;)
> nachtrag: PICs ab der reihe 18 haben keine bankings mehr.
Auszug aus [1], Kapitel 5.3:
"The data memory in PIC18 devices is implemented as
static RAM. Each register in the data memory has a
12-bit address, allowing up to 4096 bytes of data
memory. The memory space is divided into as many as
16 banks that contain 256 bytes each;
PIC18F2480/2580/4480/4580 devices implement all
16 banks. Figure 5-6 shows the data memory
organization for the PIC18F2480/2580/4480/4580
devices."
Ich frag mich, warum jeder denkt, dass die neuen PICs kein banking
haben. Vielleicht liegt es daran, dass keiner freiwillig PIC18 in
Assembler programmiert...
Microchip wird immer banking nutzen, auch wenn das den Untergang des
Unternehmens bedeuten würde LOL
[1] http://ww1.microchip.com/downloads/en/DeviceDoc/39637b.pdf
@ Super (Gast)
Die Sache mit dem RAM Banking hat (wie alle anderen auch) nicht nur eine
(negative) Seite.
Erstens benötigt man nur 8 Bit zur direkten Adressierung (spart Platz im
immediate Teil des Codes) und zum anderen gibt es ja immerhin noch 3
fsr-pointer zur indirekten Adressierung.
Wer in C programmiert kriegt davon aber sowieso nix mit.
Zu
Autor: X. H. (shadow0815)
For PIC18 gibt es ja einen C-Compiler
und der hat banking.
Das banging ist hat zur Folge, das in der Bank
schnell und mit kurzen Befehlen gesprungen werden kann - das geht bei
AVR aber ähnlich, Begriffe wie:
rel. Sprung/Addressierung oder absoluter.
Zu C + Ass: spez. bei PIC18
Ass. läßt sich ggf. nicht so einfach von PIC16
auf 18 transferieren, weil:
es gibt Ass. Befehle mit 2 Bedeutungen, da es 2 Ass.
"inside" gibt.
Ob das für die PIC16-Befehle gilt?
Den Ass.-Modus kann man umschalten - bin mir aber icht ganz sicher,
das habe ich vor over 1 Jahr mal gelesen.
"PIC" schreibt selbst, dass der eine Ass-Modus
(bzw. angepasste/optimierte Befehle) für C ist.
Was hacken hier immer alle auf den PICs rum?
Vergesst mal nicht, daß die PIC-Architektur eine sehr alte ist, älter
noch als die 8051er. Damals waren diese Krücken ganz normal.
Wer sich nen Oldtimer kauft, meckert doch auch nicht darüber, daß der
sich nicht wie ein Porsche Turbo GT fährt.
Also immer schön sachlich bleiben. PICs sind Oldtimer und darum
natürlich nicht so leistungsfähig und modern wie AVRs oder ARMs. Aber
wer einen PIC wählt, schert sich einen Teufel darum, er will halt das
Nostalgische am PIC erleben...
PIC18 haben sehr wohl ein Banking für den Zugriff auf das RAM, aber sie
haben kein Paging (mehr)! D.h. der Programmspeicher ist linear.
Das sind zwei ähnliche Konzepte, aber sind nicht zu verwechseln.
Über sog. FSR (File Select Register) kann auf das ganze RAM direkt, also
ohne Bank-Switching, zugegriffen werden.
PIC18 haben auch nicht zwei "Assembler inside", sondern sie haben einige
erweiterte Befehle, die man per Configuration Bit einschalten kann.
Ein Assembler ist ein Programm, welches ein Assembler-File in
Maschinensprache umsetzt. Ein Prozessor versteht nur Maschinensprache.
Die "Assembler-Befehle" sind sog. Mnemonics, also eine Darstellung, die
sich ein Mensch einfacher merken kann als ingendwelche Hex-Zahlen.
Severino
@Dieter:
Ähhhh, als ich mit PICs angefangen habe da wollte ich nicht das
nostalgische Feeling haben.... ich dachte das wäre ein moderner
Mikrocontroller, der schön zu programmieren sei.
So schlecht sind die PICs ja auch nicht. Im Gegenteil: Die Teile
(zumindest die Alten) halten extrem viel aus.
Ich finde die AVRs aber mittlerweile sehr viel besser... in ASM sind die
einfach prima zu programmieren, obwohl die für C optimiert wurden.
Gruß,
SIGINT
> D.h. der Programmspeicher ist linear.
Mal ganz blöd gefragt, aber welcher PIC hatte denn keinen linearen
Programmspeicher? Ich kann mich nicht erinnern, dass der
Programmspeicher eines PICs jemals in "pages" unterteilt war. Irgendwie
stehe ich gerade auf dem Schlauch.
> Programmspeicher? Ich kann mich nicht erinnern, dass der> Programmspeicher eines PICs jemals in "pages" unterteilt war. Irgendwie> stehe ich gerade auf dem Schlauch.
Schau dir mal die PIC16-Reihe an.
Bri wrote:
> Bin ich der einzige, der sich über die 13V Programmierspannung bei PICs> aufregt? Bei den AVRs sieht man doch, dass es auch ohne geht.
Teils richtig. Bei den PICs gibt es auch LV-Typen. Und bei den AVRs
kannst du mal versuchen, den AVR wieder zu beschreiben, wenn du SPIEN
falsch gesetzt hast. Oder verwende doch mal den Reset Pin als I/O.
>Bin ich der einzige, der sich über die 13V Programmierspannung bei PICs>aufregt?
He? Schon mal was von "low voltage programming" gehört?
Z. B. PIC16F628, DS40044D, Seite 112
Die 12bitter sind da eine ganz besondere Nummer: Von jeder Bank ist nur
die erste Hälfte per CALL erreichbar, in die zweite Hälfte kommt man nur
per GOTO.
Super wrote:
> Mal ganz blöd gefragt, aber welcher PIC hatte denn keinen linearen> Programmspeicher? Ich kann mich nicht erinnern, dass der> Programmspeicher eines PICs jemals in "pages" unterteilt war.
Da wollte ich grad auf die SX-Familie von UBICOM verweisen, da konnte
jede 2.Page nicht mal Ziel eines CALL sein.
Aber nun sehe ich, die wurden ja schon 2005 wieder eingestampft.
Da konnte sich trotz der 75MIPS (100MIPS beworben) wohl keiner für
erwärmen.
Man hätte ja auch nicht gerade die allerälteste Architektur (PIC12-Core)
aufpimpen müssen.
Peter
Ich arbeite gerade aktiv mit verschieden PIC's.
Und ich wollte auf einen Thread antworten bei dem es um USB ging.
Ich bin neu im Forum und habe ausversehen auf "neuer Thread" geklickt.
Und in diesem Thread in dem ich antworten wollte, ging es nur um OTP.
Und außerdem gibt es bei PIC nur Microcontroller mit OTP die sich
gleichsam mit JDM-Programmer programmieren lässt. Alle anderen USB-PIC's
sind 18fxxx, und für diese braucht man ein etwas aufwendigeren
Programmer.
Schau mal
http://www.microchip.com/ParamChartSearch/chart.aspx?branchID=111&mid=10&lang=en&pageId=74
Sorry
Habe hier wohl eine grundsatz-Diskusion vom Zaun gebrochen.
Wollte eigentlich nur auf eine Frage in einem Thread antworten.
Wenigstens gibt's Diskusionsstoff !!
@ Marco Schwan
Es war ja nicht explizit die Rede vom PIC16F876.
Jedenfalls hat der PIC16F876 vier "Program Memory Pages", nachzulesen im
Datenbuch im Kapitel 2.1 Program Memory Organization.
Um ein Missverständnis auszuschalten:
Der Programm-Counter ist zwar 13 Bit breit, kann also alle 8k
adressieren.
Die GOTO und CALL Befehle akzeptieren jedoch nur einen 11 Bit Parameter
und ergänzen die verbleibenden 2 Bits aus dem Register PCLATH. Diese
beiden Bits adressieren die Page.
Alles klar?
Severino
Wow, das hätte ich nicht gedacht!
Warum hat Microchip denn so eine alte Architektur als Basis für alle
8Bit-Controller genommen? Das ist doch absolut unlogisch!
So schwer ist es doch wohl nicht für einen großen Halbleiterhersteller,
einen vernünftigen 8Bitter zu entwickeln, der diese ganzen Krücken
nichthat, oder?
@ Michael
Sehr oft ist es halt so, dass man etwas hat, das funktioniert.
Man kann alles immer noch etwas besser machen, und im Nachhinein ist man
klüger. Vielleicht ist man ja gar nicht so sicher, dass es ein Erfolg
wird, und will keinen grossen Aufwand treiben. Und wenn der Erfolg da
ist, ist es zu spät, um alles zu ändern, weil es sonst nicht mehr
kompatibel ist.
(die älteren Jahrgänge erinnern vielleicht an die Entstehung des IBM-PC
;-)
Einige Kriterien für einen guten Controller sind:
Gute Verfügbarkeit, auch in kleinen Stückzahlen
Dokumentation
Entwicklungssysteme
Langfristige Verfügbarkeit
Zuverlässigkeit des Produkts
Zuverlässigkeit des Lieferanten
Preis/Leistung
(Liste nicht vollständig, da viele Kriterien auch individuell)
die Architektur ist nur eines von vielen Kriterien
Ausserdem war Microchip früher, als die Architektur gewählt wurde, nicht
einer der grossen Halbleiterhersteller.
Severino
