Hallo, ich möchte eine Spannung messen und diese am LCD ausgeben. Nun habe ich mich ein wenig schlau gemacht und bin auf PIC-Mikrocontroller gestoßen - allerdings fehlt hier die Multiplikation und die benötige ich später noch... Jetzt wollte ich euch fragen, welche Alternativen es zu den PICs gibt. Sie sollten nicht zu teuer sein, mein Problem lösen können und das Wichtigste wäre ausreichend Lektüre im WWW. Vielen Danke im Voraus :)
tja, AVR. Wobei beide Familien ab einer Groesse eine hhardwaremultiplikation haben. Das sollte aber eh kein Problem sein, da man sehr einfach aus Additionen und Schieben eine Multiplikation machen kann. Ein Compiler macht das auch so.
achso, danke..... hmmm welche der beiden kannst du mir empfehlen?
Lukas wrote: > achso, danke..... hmmm welche der beiden kannst du mir empfehlen? PIC fand ich immer doof. Alles geht über das W Register, kein ADC (add with carry). Hardwaremultiplikation geht erst ab PIC18. Die AVR ISA dagegen top. Ab Atmega: 8x8 Multiplikation in 2 Zyklen (Die meisten PIC brauchen für jeden Befehl mindestens 4 Zyklen). Ausserdem gibt es einen gcc-port (d.h. C,C++ und ADA) und der kann auch in AVR-Studio integriert werden, falls man mit Windows unterwegs ist. Also ich tendiere dann doch eher zu AVR.
Wenn es dir um die Multiplikation geht: Die kann ein PIC Prozessor auch problemlos. In C programmiert steht dir das direkt zur Verfügung und in Assembler schreibst du dir Code, der aus Additionen eine Multiplikation macht.
> kein ADC (add with carry). Schau besser noch mal nach! > Hardwaremultiplikation geht erst ab PIC18. Was spricht dagegen die neuesten PICs zu verwenden?
Oh, noch was: > 8x8 Multiplikation in 2 Zyklen (Die > meisten PIC brauchen für jeden Befehl mindestens 4 Zyklen). Ein PIC der neuesten Generation benötigt dazu lediglich 40 ns.
BrunoB wrote: >> kein ADC (add with carry). > > Schau besser noch mal nach! > >> Hardwaremultiplikation geht erst ab PIC18. > > Was spricht dagegen die neuesten PICs zu verwenden? PIC18 sind im Einzelhandel ein ganzes Stück teuerer als vergleichbare AVR. Die 8x8 Hardware Multiplikation ist da übrigens auch nur unsigned, d.h. für signed musste dann noch code dazuschreiben.
> PIC18 sind im Einzelhandel ein ganzes Stück teuerer als vergleichbare > AVR. Du vergleichst nicht gerade Äpfel mit Birnen, oder? > Die 8x8 Hardware Multiplikation ist da übrigens auch nur unsigned, > d.h. für signed musste dann noch code dazuschreiben. Wenn Du gerade von Assembler sprichst, dann schau auch ruhig mal auf das C- und N-Flag (neben den anderen Flags).
>PIC fand ich immer doof. Ich finde es doof, wenn sich Leute über Dinge, von denen sie keine Ahnung haben, negativ auslassen. >Alles geht über das W Register, kein ADC (add >with carry). Hardwaremultiplikation geht erst ab PIC18. Das W-Register ist nunmal dazu da, um benutzt zu werden. Aber was meinst du bitte mit 'alles'?! ADD w/Carry gibts auf jedem PIC! >Die AVR ISA dagegen top. Ab Atmega: 8x8 Multiplikation in 2 Zyklen (Die >meisten PIC brauchen für jeden Befehl mindestens 4 Zyklen). Was hast denn da falsch aufgeschnappt? Die Pipeline ist bei jedem PIC gleich lang. >> Hardwaremultiplikation geht erst ab PIC18. >Was spricht dagegen die neuesten PICs zu verwenden? Man müsste dann ja zugeben, dass es Programmierer- und Comnpilerfreundliche PICs gibt ;) Gruss, Edson
Meister Eder wrote: >>Alles geht über das W Register, kein ADC (add >>with carry). Hardwaremultiplikation geht erst ab PIC18. > > Das W-Register ist nunmal dazu da, um benutzt zu werden. Aber was meinst > du bitte mit 'alles'?! Ich meine: W ist Akkumulator. Einen designierten Akkumulator zu haben vereinfacht vielleicht das chip-design, aber den code macht es definitiv umständlicher (länger, langsamer). > > ADD w/Carry gibts auf jedem PIC! ADDWFC ist erst mit PIC17 dazugekommen. Wenn du es für die Vorgänger belegen kannst, dann bitte. > Ich finde es doof, wenn sich Leute über Dinge, von denen sie keine > Ahnung haben, negativ auslassen. [sic] > >>Die AVR ISA dagegen top. Ab Atmega: 8x8 Multiplikation in 2 Zyklen (Die >>meisten PIC brauchen für jeden Befehl mindestens 4 Zyklen). > > Was hast denn da falsch aufgeschnappt? Die Pipeline ist bei jedem PIC > gleich lang. Was hat das mit Pipeline zu tun? Bei 40 MHz Takt schaffen die PIC 10 MIPS. AVR schaffen 10 MIPS bei 10 MHz. Da kann man natürlich sagen "nimmste halt 'n 40 Mhz Quartz". Aber wenn du z.B. mit einer externen clock arbeiten willst/musst hat der AVR einfach die Nase vorn.
"AVR schaffen 10 MIPS bei 10 MHz. Da kann man natürlich sagen "nimmste halt 'n 40 Mhz Quartz". Aber wenn du z.B. mit einer externen clock arbeiten willst/musst hat der AVR einfach die Nase vorn." PIC haben eine x4 PLL - 10MHZ genuegt;-)
Gerhard. wrote: > "AVR schaffen 10 MIPS bei 10 MHz. Da kann man natürlich sagen "nimmste > halt 'n 40 Mhz Quartz". Aber wenn du z.B. mit einer externen clock > arbeiten willst/musst hat der AVR einfach die Nase vorn." > > PIC haben eine x4 PLL - 10MHZ genuegt;-) PIC18 haben eine x4 PLL (Achtung:Jitter!) und auch nicht alle. AVR können bis zu 20 MHz ab und sind dann doppelt so schnell wie ein PIC.
Luther Blissett wrote: > PIC18 haben eine x4 PLL (Achtung:Jitter!) und auch nicht alle. AVR > können bis zu 20 MHz ab und sind dann doppelt so schnell wie ein PIC. ...der mit 40MHz läuft. und brain: Nein. http://www.microcontroller.com/news/microchip_pic18_40mhz.asp "All Microchip PIC18 microcontrollers execute one instruction every machine cycle. A machine cycle is 4 clock cycles. This gives 10 MIPS performance @40 MHz and translates into 10 MHz access to either internal or external Flash memory. With the internal 4 x PLL circuit, an external 10 MHz crystal can be used to obtain an internal 40 MHz clock."
> und brain: Nein. Doch: 16 MIPS bei 16 MHz externen Quarz!!! siehe zum Beispiel (FIGURE 2-1, page 25): http://ww1.microchip.com/downloads/en/DeviceDoc/41303C.pdf > (Achtung:Jitter!) Beschreib doch mal eine Applikation, bei der Dich das "Jittern" stört, bzw., bei der Du es überhaupt bemerkst?
Diese schei..... Streiterei über irgendwelche angeblichen Vorteile der einen oder anderen Produktfamilie geht mir tierisch auf den Sa.. Das war schon bei Video2000 gegen VHS, bei Amiga gegen PC, bei LP gegen CD und bei was noch alles für unsinnige Streitereien so. Was soll das immer? AVR ist besser als PIC? Jede Familie hat ihre Vor- und Nachteile. Und jede dieser Familien kann alle Probleme lösen welche die andere Familie auch kann. Und wie die Dinger nun auf ihre MIPS kommen ist doch völlig egal, Hauptsache sie schaffen es die gestellte Aufgabe in der vorgegebenen Zeit abzuarbeiten. Und das können beide Produktfamilien gleich gut! Sven
> Und das können beide Produktfamilien gleich gut!
Vielleicht, aber dafür müssten sie erst einmal lieferbar sein.
Ich bin der Ansicht dass ein Microcontroller nur gerade so schnell laufen muss um den Entwicklungsanforderungen zu genuegen;-) Wenn ich also einen Videogenerator bauen will, dann ist warscheinlich ein PIC nicht die beste Loesung und nehme an dass ein AVR oder ARM das warscheinlich besser macht (Wie einige WEB-Beispiele demonstrieren). Fuer viele andere Anwendungen ist es warscheinlich gleichgueltig welche Prozessorfamilie man nimmt und ist eher mehr von der Wahl der Peripherie oder anderen Erwaegungen abhaengig. Wie so oft in der wirklichen Welt, hat alles seine Vor- und Nachteile. Mir gefaellt zum Beispiel an PICs besser, dass das FlashROM oder das EEPROM eine wesentlich bessere Lebenserwartung hat wie die AVRs. Auch gibt es nicht die ganze Problematik mit den Fuses. PICs kriegt man viel leichter als Samples. Einige AVRs sind bei uns oft monatelang auf Allocation und nicht rechtzeitig erhaeltlich.
Luther Blissett wrote: > "All Microchip PIC18 microcontrollers execute one instruction every > machine cycle. A machine cycle is 4 clock cycles. This gives 10 MIPS > performance @40 MHz and translates into 10 MHz access to either > internal or external Flash memory. With the internal 4 x PLL circuit, an > external 10 MHz crystal can be used to obtain an internal 40 MHz > clock." Interessant und schwach zugleich. Die AVR machen zwar laengst nicht alle Instruktionen in einem Takt, aber viele brauchen nur einen oder auch zwei Takte (manche aber auch 4). Jetzt muesste man noch wissen ob der PIC-Befehlssatz komplex ist, denn wenn er das ist, kann der AVR trotzdem wieder langsam sein. Man sollte die Infos nicht so aus dem Zusammenhang reissen.
@ Michael G.: geanu! das sehe ich auch so. sowohl bei den AVRs wie auch bei den PICs gibts 1000 variationen mit diverser peripherie und allen möglichen geschwindigkeiten. ich habe mich für PICs entschieden, andere für die AVRs. es ist so wie im leben: die einen haben lieber äpfel, die anderen birnen - beide sind schmackhaft und doch leicht unterschiedlich ;)
Brain wrote: >> und brain: Nein. > > Doch: 16 MIPS bei 16 MHz externen Quarz!!! > > siehe zum Beispiel (FIGURE 2-1, page 25): > http://ww1.microchip.com/downloads/en/DeviceDoc/41303C.pdf Das ist das Datenblatt für die K20 Serie, die laufen mit bis zu 64Mhz (d.h. 16 Mhz*4), sind aber erst letzten September angekündigt worden und ich glaube nicht du kannst mir sagen wo es die zu kaufen gibt. Die funktionieren im übrigen auch nicht mehr mit 5V. Ach ja, und Bank Switching brauchen die immer noch. Brouhahaha! Ich kann > >> (Achtung:Jitter!) > > Beschreib doch mal eine Applikation, bei der Dich das "Jittern" stört, > bzw., bei der Du es überhaupt bemerkst? Solange der Takt nicht für ADC/DAC benutzt wird...
Sven Stefan wrote: > Diese schei..... Streiterei über irgendwelche angeblichen Vorteile der > einen oder anderen Produktfamilie geht mir tierisch auf den Sa.. Die Streiterei war nicht beabsichtigt, der OP wollte nur wissen was wer empfehlen würde und dann sind einige PIC Apologeten reingesprungen, die die Datenblätter nicht gelesen haben. > > Das war schon bei Video2000 gegen VHS, bei Amiga gegen PC, bei LP gegen > CD und bei was noch alles für unsinnige Streitereien so. Was soll das > immer? AVR ist besser als PIC? Jede Familie hat ihre Vor- und Nachteile. > Und jede dieser Familien kann alle Probleme lösen welche die andere > Familie auch kann. Und wie die Dinger nun auf ihre MIPS kommen ist doch > völlig egal, Hauptsache sie schaffen es die gestellte Aufgabe in der > vorgegebenen Zeit abzuarbeiten. Und das können beide Produktfamilien > gleich gut! Hängt davon ab. Meiner Meinung nach haben AVR auch bei den 2 Euro Modellen Leistungsmäßig mehr Spielraum nach oben als PIC, d.h. man hat für eine größere Menge von Problemen die Möglichkeit auf einer Plattform zu bleiben. Das ist, neben solchen Tatsachen, daß hochwertige Entwicklungstools unschlagbar preiswert verfügbar sind, viel wert.
Luther Blissett wrote: > Die Streiterei war nicht beabsichtigt, der OP wollte nur wissen was wer > empfehlen würde Mann sollte Fragen, in denen die Worte 'Meinung', 'besser' und 'Empfehlung' in einem Satz vorkommen einfach nicht zulassen. Da kommt nur Streiterei raus. Egal ob das Thema jetzt Windows - Linux, C - C++ - Bascom - Java, dieser Drucker - jener Drucker, AVR - PIC, morgens lange schlafen - morgens früh aufstehen, Cola - Pepsi, McDonalds - Burger King, .... ist, es kommt immer Streit heraus.
> Solange der Takt nicht für ADC/DAC benutzt wird... Die PIC-internen ADC und DAC kommen prima mit der PLL zurecht. Empfindliche externe Bausteine würde ich mit einem qualitativ guten externen Taktgenerator betreiben und nicht mit einem Controller-Oszillator. Je nach Anforderung findet man aber auch sehr robuste ADC und DAC, die nicht so leicht zu einem Fehlverhalten neigen. Schau dazu mal unter www.linear.com nach. Somit ist Dein Beispiel für nicht wirklich nachvollziehbar. > Die Streiterei war nicht beabsichtigt, der OP wollte nur wissen was wer > empfehlen würde und dann sind einige PIC Apologeten reingesprungen, die > die Datenblätter nicht gelesen haben. Möchtest Du mit diesem Satz sagen, daß Du nur dann nicht streitest wenn alle Deiner Meinung sind?
Michael G. wrote: > Jetzt muesste man noch wissen ob der > PIC-Befehlssatz komplex ist, denn wenn er das ist, kann der AVR trotzdem > wieder langsam sein. Wenn man hauptsächlich 8-Bit Daten verarbeitet und den Speicher direkt adressiert, sind PICs teilweise komplexer als AVR und durchaus leistungsfähig. Beispielsweise können Steuerregister und RAM Ziel von Operationen sein, was bei AVRs nur bei Einzelbits und nur bei manchen Registern möglich ist. Sobald jedoch in signifikantem Umfang 16- und 32-Bit Daten verarbeitet werden, sehen generell alle Akkumulator-Architekturen schlecht aus. Indirekt adressierter Speicher ist mindestens bei den PIC10-16 arg eigenwillig, sowohl bei ROM-Daten wie auch im RAM. Auch das Banking von Code und Daten ist nicht wirklich angenehm, weder in Assembler noch für den Compiler.
>> Die Streiterei war nicht beabsichtigt, der OP wollte nur wissen was wer >> empfehlen würde und dann sind einige PIC Apologeten reingesprungen, die >> die Datenblätter nicht gelesen haben. > > Möchtest Du mit diesem Satz sagen, daß Du nur dann nicht streitest wenn > alle Deiner Meinung sind? Ich kann natürlich Quatsch wie "ADD w/Carry gibts auf jedem PIC!" einfach so stehen lassen.
Naja danke, aber ich versteh nicht wirklich von was ihr da immer redet. Ich nehme an von AVR gibts mehr Material im I-Net?? Stellt sich noch die Frage C oder Assembler :D > Möchtest Du mit diesem Satz sagen, daß Du nur dann nicht streitest wenn > alle Deiner Meinung sind? Der war gut :D
@luther-blisset >ADDWFC ist erst mit PIC17 dazugekommen. Wenn du es für die Vorgänger >belegen kannst, dann bitte. Ok, stimmt, habe nachgesehen. Ich arbeite halt nur mit PIC18. > Die Streiterei war nicht beabsichtigt, der OP wollte nur wissen was wer > empfehlen würde und dann sind einige PIC Apologeten reingesprungen, die > die Datenblätter nicht gelesen haben. Meine PIC18-Sheets kenne ich ganz gut ;) Von wegen 'PIC Apologet', ich kann durchaus einen Fehler zugeben, so drastisch musst du das nicht sehen. Gruss, Edson
@Lukas >aja danke, aber ich versteh nicht wirklich von was ihr da immer redet. Kommt vielleicht noch... >Ich nehme an von AVR gibts mehr Material im I-Net?? Weiss ich nicht, zu PICs findet sich ebenfalls vieles. www.sprut.de >Stellt sich noch die Frage C oder Assembler :D Wenn du dich für C entscheidest, stellt sich die Controllerfrage wieder. Die Assembler-Befehlssätze von PIC und AVR-Familien kannst du dir ja mal anschauen und den nehmen, den du am leichtesten nachvollziehen kannst. Damit erledigt sich dann die 'Controllerfrage', Assembler-Kenntnisse helfen auch beim verstehen von C-Compilern. Gruss, Edson
Meister Eder wrote: > Meine PIC18-Sheets kenne ich ganz gut ;) Von wegen 'PIC Apologet', ich > kann durchaus einen Fehler zugeben, so drastisch musst du das nicht > sehen. Sorry. Mir drückt's heute schon den ganzen Tag an der Galle, da werde ich leicht garstig :-(
@Schwurbl: keine Frage, McD schmeckt besser @meister eder: OK, danke erstmal. ich hab ein paar C-Vorkenntnisse, die aber nicht ausreichen, so wies ausschaut. Braucht man bei den Assembler Tutorials auch Vorkenntnisse oder kennt jemand eines, wo man auch gleich Assembler mitlernt? Ein Link wäre echt cool! Ich schau mich mal weiter um Luki
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.