Hallo zusammen, habe mit dem PIC 18f4550 vor geraumer Zeit einige kleine Projekte gemacht (LCD, USB, Led ein/aud ;) ) und dann längere Zeit nichts. Achja ich bin Hobbyhobby-Bastler und wenn ich mit einem Controller mit Kanonen auf Spatzen schiesse ist mir das egal ;) Nun zu meiner Frage: Soll der Schuster bei seinen Leisten bleiben, oder macht es Sinn umzusatteln. Hab irgendwo gelesen, dass sich die PIC 32 "angenehmer" programmieren lassen. Oder vllt sollte ich auf die Arduino-Welle mit aufspringen um mir das Leben leichter zu machen? Von Microchip gibt es da doch auch dieses chipKIT. Einen MSP 430 hab ich auch noch, da gab es ja mal diese Einkaufswelle hier im Forum, da musste ich mitkaufen, hab das Teil aber noch nicht mal ausgepackt... Zu meinen Anforderungen kann ich nicht viel sagen, dass ist spontan, gerade habe ich mit ein BTM 222 gekauft und Temperatursensoren (1-Wire) liegen auch noch hier rumm. Bitte einfach mal die Meinung raushauen, außer es ist nicht konstruktiv sondern reine Kritik an irgendwas ;)
Einsteiger mit Pause schrieb: > Soll der Schuster bei seinen Leisten bleiben, oder macht es Sinn > umzusatteln. Moderne Mikrocontroller unterscheiden sich nur in Details. Die Unterschiede sind so gering das man sich endlos darüber streiten kann;-). Wenn du Schwierigkeiten mit einem hast wird das mit dem nächsten in nichts besser. Ein Wechsel macht kirre ohne das dadurch Voreile entstehen. Durchbeißen, selbst das Schlaraffenland hatte einen Reisberg am Eingang.
Bin vor noch nicht allzu langer Zeit von PIC18 auf PIC24 umgestiegen. Die Peripherie ist deutlich besser und nahezu identisch zum PIC32. Habe aber auch PIC32-Erfahrung. Aber auch PIC32 gibts es reichlich fertige Libraries von Microchip für viele Standartprobleme. Gerade als Hobbybastler solltest du dir die neuen PIC32 im DIP28-Gehäuse mal ansehen.
Hi, Einsteiger mit Pause schrieb: > nix dazu zu sagen? Naja, was soll man dazu schon groß sagen... Das Problem ist das ich (und wahrscheinlich auch der großteil der anderen) überhaupt nicht erkennen kann WARUM du überhaupt umsteigen möchtest. Ob die PIC32 leichter zu Programmieren sind oder nicht hängt von deinem Inidviduellen Programmierstil und natürlich auch vom Geschmack ab. Der Befehlssatz in den Librarys ist deutlich umfangreicher. Zudem ist der Aufwand damit der PIC32 überhaupt etwas tut um einiges höher. Ich würde das so sagen: Zum Lernen, als Einsteiger, ist der PIC18 DEUTLICH einfacher. Die Umsetzung großer Projekte ist dann aber auf dem PIC32 einfacher, einfach weil dieser mehr Ressourcen hat. Allerdings kann ich keinen Grund erkennen warum du nicht beide Serien nebeneinander Benutzen willst/kannst? Die IDE ist dieselbe, das Programmiergerät ist, wenn man eine gescheite Wahl getroffen hat, dasselbe. Der Befehlssatz ist über weite TEile identisch. Der PIC32 hat mehr Befehle, allerdings kann man auchmit dem Grundstock der PIC spezifischen Befehle die in beiden Compilern unterstützt sind komplette PIC32 Programme schreiben. Ist halt in einigen Fällen etwas aufwendiger als nötig... (Will man einen IO als Input setzen: Es gibt einen PIC32 BEfehl "PORTSetPinsDigitalIn" den man verwenden kann. Genauso wie es ähnliche Befehle für Analog Input oder diverse Ausgänge gibt. Aber auch ohne den Befehl geht es natürlich dann setzt man halt händisch das Tris REgister, schaltet ggf. die AD Wandler ab und auch die evtl. vorhandene andere Pripherie) Der Vorteil bei den PICs ist es ja gerade, das man mit ein und derselben Ausrüstung sowie ein und derselben ENtwicklungsumgebung eine sehr Breite Auswahl verschiedenster Controller diverser Leistungsklassen programmieren kannst. Da zudem selbst in den dem einfachen Hobbyisten zugänglichen Vertriebskanälen die angebotene Bandbreite groß ist spricht doch nichts dagegen sich jeweils den benötigten Controller auszusuchen. (NAtürlich kann man sich für einfache Dinge auf eine kleine Auswahl Controller einschränken die man auf Vorrat hat. Bei den 18ern würde ich z.B. den 18F45K20, den 18F4550 sowie als "kleinen" noch den 18F14K50 in betracht ziehen. den 45K20 sowie 14K50 bekommt man für um die 2Euro. Bei den PIC32 ist der PIC32MX795F512L so ziemlich die obere Fahnenstange der wohl alles was der Hobbybastler braucht Abdeckt. Allerdings mit um die 10Euro pro µC schon eine Hausnummer. Da macht es schonmehr Sinn auch mal etwas kleiner zu denken. Vom PIC abgesehen: Wenn du schon C Beherscht, dann würde ich ARDUINO maximal als ergänzende HArdwarebasis ansehen. Es spricht ja nichts dagenen die "Shields" für eigene ZWecke zu nutzen. Auf die eigene Sprache würde ich aber verzichten... Wenn es dir darum geht "mit Kanonen auf Spatzen" zu schiessen könnte man auch noch die ARM (am ehesten CORTEX M3) ins Spiel bringen. Allerdings sind hier die für "normale Bastler" möglichen Einkaufsmöglichkeiten beschränkt und du brauchst neue Software und HArdware. Dazu kommt das die meisten Compiler in den freien Versionen Codegrößenbeschränkt sind. Von der Leistungsfähigkeit liegen die im Bereich der PIC32. Aber auch hier gilt, das komplexe Programme deutlich einfacher sind als auf den 8Bittern, aber gerade die ganz einfachen Dinge wie "Pin Toggeln" oder generell der einsatz FÜR EINFACHE STEUERZWECKE im vErgleich zu 8Bit mehr aufwand erfordert. Aber darüber nachdenken könntest du mal. Wie gesagt, die Leistungsfähigkeit - und vor allem das Preis Leistungsverhältniss wenn man die möglichkeiten WIRKLICH Ausnutzt sind da sehr gut. (Nütz nur nichts wenn man nur 5% des Programmspeichers sowie zwei AD Wandler ausnutzt und der Rest abgeschaltet ist. Dann ist P/L grottig) Argumente gegen MSP430 fallen mir gerade fast genausowenig ein wie dafür. Wer den Mag kann den gerne Verwenden. Ich sehe allerdings in dem Wechsel keinen Vorteil gegenüber PIC. Ob die zwei NAchteile die mir einfallen in deinem Fall auch als NAchteil in erscheinung treten kannst nur du alleine beurteilen. Wobei die auch nicht gravierend sind: 1.) Der MSP430 ist ein 16Bit Controller, es gibt keine 8Bit und auch keine 32Bit Controller die du mit identischen WErkzeugen programmieren kannst. 2.) Der MSP430 ist unter Hobbyisten weniger verbreitet, also etwas geringere Bezugsmöglichkeiten und Unterstützungsmöglichkeiten in Foren o.ä. (Für kommerziellen Einsatz spielt beides keine Rolle) NAtürlich könnte man noch einen Wechsel auf AVR in Betracht ziehen. Aber auch hier sehe ich keine Vorteile. ISt in etwas gleichwertig. Was unterschiedlich ist, das ist der Support mit Software und Librarys. Für den AVR kommt sehr viel aus der "Community" und verhältnissmäßig wenig von ATMEL selbst. Beim PIC kommt eine sehr breite Softwareunterstützung vom HErsteller. Da dadurch aber Bedarf für Selbstentwickeltes gering ist weniger aus Drittquellen. Es ist eine Geschmackssache was man besser findet. Ich plädiere ganz stark für "alles aus eine Hand", was dann PIC bevorteilt. Aber andere sehen es anders. Ein ähnlichen Unterschied gibt es bei der Modellpalette. AVR haben eine recht überschaubare PAlette mit durchaus Leistungsfähigen Controllern (viel Speicher, viel Peripherie)die sich teilweise nur im GEhäuse unterscheiden. Universalisten halt. PIC hat zwar auch solche Generalisten die man als Standardcontroller nehmen kann, aber eine sehr viel breitere und vor allem besser verfügbare Palette an "SPEZIALISTEN" (So waren USB AVR bis vor kurzem für Hobbyistren nur über einige kleine Händler teuer zu bekommen. Mittlerweile hat die aber Reichelt auch) Auch hier ist es wieder eine Geschmacksfrage... Ein für einige Bastler wichtiger Punkt ist das Gehäuse der µC. Atmel bringt viele AVR nur noch in SMD heraus. So gibt es z.B. KEINE AVR mit USB Schnittstelle in DIP. Microchip hingegen bringt bei so gut wie allen µC die mit 40 Pinne oder weniger daherkommen auch immer noch eine DIP version heraus die man dann bequem auch auf Lochraster oder Steckbrett verwenden kann. Auch 16Bit, ja sogar, wie ich die Tage erst bemerkt habe, 32BIT µC sind in DIP verfügbar! Aber auch hier kannst nur du selber beurteilen ob das ein argument für dich ist. Also: Beurteilen kannst nur du selbst. ICh würde bei PIC Bleiben, da kennst du die Software und verfügst über die Hardware. Compiler sind ohne jede Größenbeschränkung in der freien Version verfügbar. Gute SW unterstützung. Lernen und wissen Vertiefen ruhig weiter auf den 18F. Wenn es das Projekt zulässt auch ruhig mit einem kleineren PIC als den 4550 für 4 Euro. Pics derselben Leistungsklasse ohne USB gibt es schon für 2 Euro. ISt dann der Bedarf mal für mehr Rechenleistung da, dann greifst du für dieses Projekt halt zum PIC24 oder gar PIC32... ganz nach belieben. Funktioniert ja alles mit derselben IDE und Programmierhardware. Aber das ist nur meine Meinung unter Berücksichtigung MEINER Prioritäten. Du musst dir schon selber Gedanken machen. Gruß Carsten
Vielen Dank für diesen langen und hilfreichen Post. Ich denke, ich bleibe dann bei den PIC18f und schaue mir ein wenig die Beispielcodes für die PIC32 an. Sollten diese mir besser gefallen, kann ich ja wechseln oder beides betreiben. Vielen vielen Dank.
Carsten Sch. schrieb: > Wenn du schon C Beherscht, dann würde ich ARDUINO maximal als ergänzende > HArdwarebasis ansehen. Es spricht ja nichts dagenen die "Shields" für > eigene ZWecke zu nutzen. Auf die eigene Sprache würde ich aber > verzichten... Kannst du mal bitte erklären was "die eigene Sprache" ist?
arduino schrieb: > Carsten Sch. schrieb: >> Wenn du schon C Beherscht, dann würde ich ARDUINO maximal als ergänzende >> HArdwarebasis ansehen. Es spricht ja nichts dagenen die "Shields" für >> eigene ZWecke zu nutzen. Auf die eigene Sprache würde ich aber >> verzichten... > > Kannst du mal bitte erklären was "die eigene Sprache" ist? Ja, "eigene Sprache" ist evtl. nicht ganz korrekt, ABER: ISt es nicht so, das zu dem Konzept ein stark vereinfachtes C gehört? JA - ich weiß der Grundstock ist C und wenn ich das jetzt richtigim Kopf habe sogar gcc als Compiler. Aber es ist doch so, das wer mit Arduino zurecht kommt nicht zwangsläufig auch andere C programmierbare µC ans laufen bekommt. Andersherum aber geht es. GRuß Carsten
>Zum Lernen, als Einsteiger, ist der PIC18 DEUTLICH einfacher. Der hat aber immer noch ein rel. schlechte Architektur. PIC24,33 ist da viel besser, und ist zT abwärtskompatibel. PIC32 ist was ganz anders, ist MIPS. (Perif. allerdings ähnlich)
Carsten Sch. schrieb: > Ja, "eigene Sprache" ist evtl. nicht ganz korrekt, ABER: ISt es nicht > so, das zu dem Konzept ein stark vereinfachtes C gehört? > JA - ich weiß der Grundstock ist C und wenn ich das jetzt richtigim Kopf > habe sogar gcc als Compiler. Aber es ist doch so, das wer mit Arduino > zurecht kommt nicht zwangsläufig auch andere C programmierbare µC ans > laufen bekommt. Andersherum aber geht es. Es ist C/C++. Da werden noch ein paar Funktionsprototypen generiert und das war es dann. Jemand der sich ernsthaft mit dem Arduino auseinandersetzt, wird schnell auch mit den AVRs klar kommen. Interessant ist übrigens auch das Arduino-Framework auf den anderen AVRs einzusetzen...
MCUA schrieb: >>Zum Lernen, als Einsteiger, ist der PIC18 DEUTLICH einfacher. > Der hat aber immer noch ein rel. schlechte Architektur. Was ist daran schlecht und inwiefern ist das für C und/oder für Anfänger relevant? > PIC24,33 ist da > viel besser, und ist zT abwärtskompatibel. > PIC32 ist was ganz anders, ist MIPS. (Perif. allerdings ähnlich) Warum bzw. in welcher Hinsicht ist der PIC24,33 "viel besser"?
Nimm eine ARM-System mit Linux, kostet fast nix und Du hast so viele Moeglichkeiten der Programmierung ... Einzige Einschraenkung ist vielleicht, wenn Du harte Echtzeitfaehigkeit brauchst, aber das ist ja eher selten. Aber allein die Erfahrung "auf einem uC direkt zu programmieren" ist schon ein Erlebnis. Gruss hro
hro schrieb: > Nimm eine ARM-System mit Linux, kostet fast nix und Du hast so viele > Moeglichkeiten der Programmierung ... Man kann auch mit nem 40-Tonner nen einzelnen Schuhkarton transportieren... Uns man braucht nicht für jede Aufgage ein ausgewachsenes Betriebssystem, das selbst noch eine Menge Resourcen frisst. Versuch mal, ohne externen RAN und Flash Linux auf nem ARM laufenzulassen. Definiere doch mal "fast nix". Industrielle Systeme OEM-Boards gehen bestenfalls bei 60 EUR los. Wenn du irgendwelches Consumer-Schüttgut wie z.B. Dockstar zweckentfrremdest bist du immernoch ca. 20 EUR los. Gegenüber ca. 2 EUR für ne 8-Bitter. Und da vergleicht man auch schon Äpfel mit Birnen. Wie willst du an einfertiges Consumergerät vernunftig eigene Peripherie anbinden? Z.B. Analogeingänge, PWM, I²C-Temperatursensoren...etc.
heinzhorst schrieb: > hro schrieb: >> Nimm eine ARM-System mit Linux, kostet fast nix und Du hast so viele >> Moeglichkeiten der Programmierung ... > > Man kann auch mit nem 40-Tonner nen einzelnen Schuhkarton > transportieren... Ja, ich verstehe auch nicht, daß immer so maßlos übertrieben werden muß. Mein Lieblings-MC ist ein 8-Pinner (ATtiny25), für kleine Projekte ideal und bequem in C zu programmieren. Und wenn ich mehr IO-Pins brauche, kommt einfach der 14-Pinner (ATtiny24) bzw. 20-Pinner (ATtiny261). Der 28-Pinner (ATmega328p) ist bei mir schon der Bolide für riesig große Programme. Ich mag es auch, daß ich nur einen Chip in die Schaltung einsetzen muß. Und nicht ein teures Board mit nem Linux-MC und der benötigten riesen externen Beschaltung. Peter
Also ich bin vor einiger Zeit weil ich mehr Rechenperformance benötigte von PIC16/PIC18 auf dsPIC umgestiegen und habe es allgemein nicht bereut. Dort gibt es die kleinen Controller (mit wenig pins und kleine Bauform) aber eben auch etwas leistungsfähigere. Zudem ist für den Betrieb kaum Peripherie notwendig. Ich habe es auch deshalb nicht bereut, weil die Hardwareausstattung besser ist. Wenn es dir bei der Entwicklung um gute Debugging-Möglichkeiten geht, dann dünken mich andere Controller / Plattformen besser. Wenn ich mir da z.B. gcc in Verbindung mit einem ARM-Controller anschaue. Es gibt wahrscheinlich auch mehr Libraries, die man ungehinderter übernehmen kann. Kommt halt sehr auch darauf an was du machen möchtest und was dir dabei wichtig ist. Beste Grüsse Andi PS: Ein Kollege von mir programmiert seit Jahren mit PIC10 und PIC12 und ich bin immer wieder erstaunt, was er mit dieen putzigen Controller all so Schönes machet. Irgendwie hat das Kleine auch seinen Reiz
Wenn's klein sein MUSS oder ein Massenprodukt herauskommen soll oder es "nur" fuer den privaten Spass ist, dann haben die kleinen schnuckeligen uCs sicher ihre Berechtigung (ich programmiere darauf auch oft in Assembler wg. harter Echtzeitfaehigkeit und weil's klein sein muss). Wenn es aber auf eine universelle Plattform ankommt, die man moeglichst universell einsetzen will, wenn Zeit fuer das Programmieren Geld kostet, wenn Rechenpower gefragt ist, wenn Anschlussmoeglichkeiten wie z.B. Netzwerk, USB usw. benoetigt wird, dann ist ein Linux-System die bessere Wahl. Und ja, kostet so ab ca. EUR 50, bei Massenkauf sicher guenstiger, aber dann kommen ja evtl. wieder die Vorteile des uCs zum Tragen. Und zum Thema "Kanonen auf Spatzen": Ich hoffe, Ihr nutzt dieses Forum nur auf einer Textkonsole. Gruss hro
hro schrieb: > Ich hoffe, Ihr nutzt dieses Forum > nur auf einer Textkonsole. Wie soll ich denn da die Werbung sehen? Irgendwie muss der Laden hier ja auch finanziert werden.
Andreas schrieb: > PS: Ein Kollege von mir programmiert seit Jahren mit PIC10 und PIC12 und > ich bin immer wieder erstaunt, was er mit dieen putzigen Controller all > so Schönes machet. Zu den PIC10 hat Atmel auch pinkompatible ATtiny4..10. Blöder Weise hat Atmel da aber die Architektur drastisch geändert, so daß sie nicht mehr vom AVR-GCC unterstützt werden. Und C-Programmierung möchte ich auch für kleine Anwendungen nicht mehr missen. Mit Codevision bzw. IAR kann man aber die 6-Pinner AVR auch in C programmieren. Peter
;) So ne Code-Vergleichseite gibt es nicht zufällig (AVR, Arduino, PIC18,PIC24, MSP, "Linux"). Am besten zieh ich mir wohl einfach für jeden die klassiches Beispiele für ne blinkende LED. Es ist zwar HArdware nah, aber manchmal nervt mich das schon mit den einstellen der Register und der Grundeinstellung bei den PIC. Da wäre mir ein PortPinA0= Output; PortPinA0=1 schon ganzt genehm.
Einsteiger mit Pause schrieb: > Es ist zwar HArdware nah, aber manchmal nervt mich das schon mit den > einstellen der Register und der Grundeinstellung bei den PIC. > > Da wäre mir ein > > PortPinA0= Output; > > PortPinA0=1 Naja.. In PIC-ASM: PortPinA0 = Output -> bcf TRISA,0 PortPinA0 = 1 -> bsf PORTA,0 bzw. bcf LATA,0 Und in C: TRISA &= 0b11111110; PORTA |= 0b00000001; Da viele C-Compiler (zumindest alle, die ich bisher benutzt habe) einen bit-Datentyp eingefügt haben, gibt es auch noch sowas wie: LATAbits.LATA0 = 1; oder (mikroE z.B.): sbit Ausgang0 at RA0_bit; ... Ausgang0 = 1; Einsteiger mit Pause schrieb: > So ne Code-Vergleichseite gibt es nicht zufällig (AVR, Arduino, > PIC18,PIC24, MSP, "Linux"). Das würde mich auch mal interessieren. Jedoch.. Was muss/soll gemacht werden. Mit oder ohne initialisierung. USB geht wohl auf nem Linux besser als auf nem PIC oder AVR aber dafür ist ein Ausgangsbit setzen wohl beim AVR/PIC einfacher..
Michael Skropski schrieb: > Einsteiger mit Pause schrieb: >> Es ist zwar HArdware nah, aber manchmal nervt mich das schon mit den >> einstellen der Register und der Grundeinstellung bei den PIC. >> >> Da wäre mir ein >> >> PortPinA0= Output; >> >> PortPinA0=1 > > Naja.. In PIC-ASM: > PortPinA0 = Output -> bcf TRISA,0 > PortPinA0 = 1 -> bsf PORTA,0 bzw. bcf LATA,0 > > Und in C: > TRISA &= 0b11111110; > PORTA |= 0b00000001; > Da viele C-Compiler (zumindest alle, die ich bisher benutzt habe) einen > bit-Datentyp eingefügt haben, gibt es auch noch sowas wie: > LATAbits.LATA0 = 1; > > oder (mikroE z.B.): > sbit Ausgang0 at RA0_bit; > ... > Ausgang0 = 1; > > > Einsteiger mit Pause schrieb: >> So ne Code-Vergleichseite gibt es nicht zufällig (AVR, Arduino, >> PIC18,PIC24, MSP, "Linux"). > > Das würde mich auch mal interessieren. Jedoch.. Was muss/soll gemacht > werden. Mit oder ohne initialisierung. USB geht wohl auf nem Linux > besser als auf nem PIC oder AVR aber dafür ist ein Ausgangsbit setzen > wohl beim AVR/PIC einfacher.. Sieben Funktionen implementieren (vier liefern nur eine Konstante zurück) bzw., wenn es für die Anwendung reicht, übernehmen (USB MSD mit internem Flash) und dazu ein paar ein Definitionen anpassen http://ww1.microchip.com/downloads/en/AppNotes/01189a.pdf HID und CDC http://ww1.microchip.com/downloads/en/AppNotes/01163a.pdf http://ww1.microchip.com/downloads/en/AppNotes/01164a.pdf sind ebenso einfach umzusetzen bzw. können übernommen und erweitert werden.
Wie gesagt, USB hab ich ja auch ans laufen bekommen, geht schon irgendwie ;) Ich denke halt manchmal muss man sich zu viele Gedanke num die Register etc. machen, kann auch sein, dass mir meine Gedanken da gerade einen Streich spielen, hatte noch keine Zeit reinzuschauen. Für die LCD Ansteuerung hab ich mir ja auch nur ein paar "Einfache" Funktionen gebastelt um das LCD zu bedienen. Aber ich denke da manchmal so an die Richtung VBA, wenn da ne Zelle Rot sein soll, dann sag ich Zelle sei rot cells(1,1).interior.colorindex= 4 (weiß noch nicht mal ob das gerade stimmt :) ) die ersten Zeilen beim Pic gehen ja auch erstmal ans initalisieren verloren, ok wenn man es reicht ja strg+c und strg+v und der aufwand ist gleich Null. Deswegen ja die Idee/Frage, was tun, damit man eine blinkende LED sieht.
Einsteiger mit Pause schrieb: > Am besten zieh ich mir wohl einfach für jeden die klassiches Beispiele > für ne blinkende LED. Z.B. AVR-GCC:
1 | #define F_CPU 1e6 // 1MHz
|
2 | |
3 | #include <util/delay.h> |
4 | #include "sbit.h" |
5 | |
6 | int main() |
7 | {
|
8 | DDR_B0 = 1; // output |
9 | while(1){ |
10 | PORT_B0 = !PORT_B0; // toggle |
11 | _delay_ms( 200 ); // wait |
12 | }
|
13 | }
|
Peter
/** I N C L U D E S
**********************************************************/
#include <p18cxxx.h>
#include "delays.h" // für die Warteschleife
/** Configuration
********************************************************/
#pragma config OSC = HS //CPU=20 MHz
#pragma config PWRT = ON
#pragma config BOR = OFF
#pragma config WDT = OFF //Watchdog Timer
#pragma config LVP = OFF //Low Voltage ICSP
/** D E C L A R A T I O N S
**************************************************/
#pragma code
void main(void)
{
LATB = 0x00;
TRISB = 0xFE;
while(1)
{
LATB = 1;
Delay10KTCYx(100);
LATB = 0;
Delay10KTCYx(100);
}//end while
}//end main
Peter Dannegger schrieb: > Z.B. AVR-GCC:#define F_CPU 1e6 // 1MHz > > #include <util/delay.h> > #include "sbit.h" > > int main() > { > DDR_B0 = 1; // output > while(1){ > PORT_B0 = !PORT_B0; // toggle > _delay_ms( 200 ); // wait > } > } Och nö...das blockiert doch.
Wobei das auf Sprut, wenn ich mich richtig erinnere so auch nicht funktioniert. Anstatt OSC war das FOSC glaube ich. Das ist auf jedenfall das PIC Beispiel :)
OK, wenn man NUR, die LED hat, dass reicht das ja. Mit Tick-Modul aus ner Lib von Microchip:
1 | #include "HardwareProfile.h" |
2 | #include "Tick.h" |
3 | |
4 | TICK mytick; |
5 | |
6 | void main(void){ |
7 | |
8 | TickInit(); |
9 | |
10 | while(1){ |
11 | |
12 | if((TickGet()-mytick)>TICK_SECOND){ |
13 | mytick = TickGet(); |
14 | MYLED_IO ^= 1; |
15 | }
|
16 | |
17 | MachIrgedwasAnderes(); |
18 | |
19 | }
|
20 | }
|
Ist zwar nicht unbedingt für hart echtzeitfähige Sachen zu Empfehlen, aber dafür reicht's.
heinzhorst schrieb: > Och nö...das blockiert doch. Kein Problem, wozu gibts Interrupts:
1 | // Target: ATtiny13
|
2 | #define F_CPU 1e6 // 1MHz
|
3 | |
4 | #include <avr/interrupt.h> |
5 | #include "sbit.h" |
6 | |
7 | int main() |
8 | {
|
9 | DDR_B0 = 1; // output |
10 | TCCR0A = 1<<WGM01; // Mode 2: CTC |
11 | TCCR0B = 1<<CS02 | 1<<CS00; // F_CPU / 1024 |
12 | OCR0A = F_CPU / 1024.0 * 0.2 - 0.5; // every 200ms |
13 | TIMSK0 = 1<<OCIE0A; // compare interrupt |
14 | sei(); // Interrupts on |
15 | while(1){ |
16 | }
|
17 | }
|
18 | |
19 | ISR( TIM0_COMPA_vect ) // Interrupt handler |
20 | {
|
21 | PORT_B0 = !PORT_B0; // toggle |
22 | }
|
Peter
Einsteiger mit Pause schrieb: > ... > Ich denke halt manchmal muss man sich zu viele Gedanke num die Register > etc. machen, kann auch sein, dass mir meine Gedanken da gerade einen > Streich spielen, hatte noch keine Zeit reinzuschauen. Naja, für C stimmt das in gewissem Maß für die SFR. So musst du alle HArdwareeinstellungn direkt setzen. Also ob der IO nun Ausgang oder EIngang ist - oder ob da jetzt ein ADC oder Digital in am Werk sein soll. Das muss mindestens einmal geschehen, wenn sich einstellungen während der Laufzeit ändern mehrmals. Aber mit geschickter Programmierung kann man dies erheblich vereinfachen. Setzt natürlich ein wenig Erfahrung vorraus im wirklich gut darin zu werden. Aber du WILLST ja LERNEN ;-) Für ASM ist das natürlich anders. Da sind direkte zugriffe auf die GPR Register (aka RAM) wohl mit der zentrale Bestandteil des ASM. > > Für die LCD Ansteuerung hab ich mir ja auch nur ein paar "Einfache" > Funktionen gebastelt um das LCD zu bedienen. > > Aber ich denke da manchmal so an die Richtung VBA, > > wenn da ne Zelle Rot sein soll, dann sag ich Zelle sei rot > > cells(1,1).interior.colorindex= 4 > > (weiß noch nicht mal ob das gerade stimmt :) ) > > die ersten Zeilen beim Pic gehen ja auch erstmal ans initalisieren > verloren, ok wenn man es reicht ja strg+c und strg+v und der aufwand ist > gleich Null. Was meinst du jetzt mit Initialisieren? Das generelle Initialisieren des µC beim Startup oder das sich wiederholende Initialisieren beim Zugriff auf externe Elemente mit komplexer Befehlsfolge? Für das erstere, KLAR! Das ist nun einmal da. Bei den 32Bittern noch deutlich Umfangreicher benötigt. Aber das geschieht beim PC (oder µC mit Linux) ja auch, da bemerkst du es im Idealfall halt nicht weil es da das Betriebssystem macht! (Aber wehe du hast keinen passenden Treiber und musst den erst einmal selbst schreiben...) Ich habe mir mittlerweile für jeden µC Typ den ich jemals bearbeitet habe ein "Startfile" als Blankofile erstellt in dem die Fuses alle gesetzt werden, die IRQ Sprungziele definiert sind und ein unterprogramm Init vehanden ist, das aus main{} dann als erstes mit Init(); aufgerufen wird. Wenn ich ein neues Projekt starte nehme ich diese Files immer als Ausgangspunkt, benenne dann eine Kopie auf den Projektnamen um und los gehts. NAtürlich habe ich auch Abweichende Einstellungen, aber dann brauche ich nur diesen Punkt ändern... Ist im Prinzip aber auch nur die Bequemere VErsion von Copy&Paste. Wenn du die jeweilige Einleitung des Zugriffes auf Komponennten wie Displays meinst, dann bist du mit den Selbstgeschriebenen Routinen schon auf dem richtigen Weg, musst die nur erweitern. Als nächstes Schreibst du dann halt eine Routine für jedes Objekt welches du häufiger erstellen willst eine Routine die dir dieses Zeichnet. Wenn es zum Beispiel eine Tabellenzelle ist, dann kann man das durchaus so machen das man entweder die 4 eckkoordinaten oder eine Eckkordinate als Größe erstellt. Erstellt man dies dann auch noch so das die einzelnen Zellen in einem mindestns 2Dimensionalen Array abgelegt kann man später durch Index darauf zugreifen und z.B. eine Funktion schreiben die dann ähnlich wie in deinem VBA Beispiel beispielsweise an jeder Stelle im Programm mit einem Simplen DisplayOut(Anzeigestelle, Farbe); die Farbe Beliebig ändern kann. ALLERDINGS: Bei "echten" Grafikdisplays, insbesondere mehrfarbigen, wo dann auch wirklich Grafikelemente die später noch bearbeitet und weiterhin als Einzelne elemente Adressierbar bleiben sollen ist der Aufwand schon sehr hoch den man "treiben" muss bevor man die eigendliche Anwendug schreibt. Allerdings bieten mittlerweile einige Anbiebter selbst spezielle Librarys zur Verfügung die man einbinden kann. Im Fall von Microchip PIC macht das Microchip selber und das auch kostenlos: http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2680&dDocName=en543091 HAt man solche Libs zur Verfügung reduziert sich der Aufwand natürlich Enorm und man kann nahezu direkt mit der Applikation starten. Natürlich sollte hier nicht vergessen werde zu erwähnen das solche Grafikdinge für einen 8Bit µC teilweise schon wirklich eine Aufgabe sind. Simples Pixelweises Bildermalen mag noch drinn sein, komplexe Grafik ist aber nicht mehr effizient möglich. (Deshalb ist die MC Lib auch erst ab PIC24.) Vorteil bei den PICs hier, ist das man ja beliebig für solche Anwendungen dann den "großen" nehmen kann und beim nächsten mal für eine Modellbaublinklichtanwendung IM Modell mit der selben Ausrüstung dann den PIC10 und für die Steuerung der Weichen über usb dann wieder den PIC18. Bei PIC muss man sich deswegen GERADE NICHT auf eine Architektur festlegen. Für die ersten Schritte: JA-macht Sinn, sobald man es aber beherscht und Effektiv Anwendungen programmieren will kann man beliebig von PIC10 über Pic24/dSPIC bis zu PIC32 jeweils den passenden auswählen. > Deswegen ja die Idee/Frage, was tun, damit man eine blinkende LED sieht. Für die 8Bitter hast du ja jetzt schon Beispiele bekommen. Bei den 32Bittern OHNE Betriebssystem ist das ähnlich. Im Detail unterscheiden sich die Befehle manchmal etwas, aber vom Initvorgang abgesehen ist der Aufwand gleich. Bei Systemen mit Betriebssystem wie ARM9 mit LINUX hast du nicht mehr Zwangsläufig den direkten Zugriff auf die Hardware zu regeln. Das Arbeiten ist mit dem Programmieren eines PCs schon recht vergleichbar. Ich finde ein gutes (Gedanken-)Experiment ist folgendes: Will man wissen wie es ist, dann besorge man sich einen Älteren funktionsfähigen PC mit mehreren Parallelen Schnittstellen (LPT) und einer NEtzwerkkarte. Auf diesem PC wird nun Linux Installiert, danach Monitor und Tastatur abgebaut. Sämtlicher Zugriff erfolgt nun nur noch über Netzwerk. DAS IST DANN DEIN ENTWICKLUNGSSYSTEM. Jetzt kannst du mit einem "normalen" Compiler der in der LAge ist Linuxverständliche Binaries zu generieren deine Software als Schreiben und die kompilierten Programme auf den "RemotePC" schreiben. Willst du z.B. eine LED Bliken lassen müsstest du in C eine Anwendung schreiben die wie beim normalen PC auch immer eine Leitung ON/OFF setzt. (Beim "echten" LinuxµC ist das natürlich kein LPT und ein Treiber für direkten IO Zugriff ist meist dabei). Will man dann z.B. ein Modem oder eine Soundkarte anschließen installiert man zusätzlich den Treiber dafür, hat man keinen muss man einen Programmieren. In dieser Konfiguration hat man also mit der HArdware im Anwendungsprogramm nur noch wenig zu tun, das System hat schon deutliche Ähnlichkeit mit einem richtigen "Computer" Einen großen Vorteil hat man durch das Betriebssystem wenn man über wirklich Leistungsfähige Hardware verfügt und in Richtung Multitasking oder ähnliches gehen Will. Hinsichtlich des Zugriffes auf externe/interne HArdware kommt es dann sehr darauf an ob passende Treiber verfügbar sind. Hat man zugriff auf für seine Hardware passende Treiber so muss dieser beim Start des Betriebssystems eingebunden werden und innerhalb der Anwendung braucht man dann nur noch auf die durch den Treiber bereitgestellte Schnittstelle zugreifen. Hat man keinen Treiber, so muss man erst einen selbst schreiben, der dann aber im gegensatz zur Version ohne BS sowohl die Richtige Kommunikation mit der Hardware ALS AUCH den Anforderungen des Betriebssystems gerecht werden muss. Letzten endes ist, wenn man es genau betrachtet, der HArdwarezugriff also nicht einmal einfacher. Der Unterschied ist nur wo die Unterstützenden Dateien eingebunden werdem. Bei Linuxsystemen ins Betriebssystem, bei Controllern ohne BS ist es halt die Lib die direkt als Include in den Programmcode eingebettet wird. Das was manche meinen ist einfach nur das mittlerweile in den Linuxversionen für Controller von Haus aus viele Treiber eingebunden sind, wohingegen man sonst zumindest noch die datei einmal aktiv ins C Projekt aufnehmen muss. Diese Systeme haben DEFINITIV Ihre Berechtiung, keine Frage. Wenn man immer mehr Leistung braucht kommt irgendwann der Punkt an dem man nicht mehr drumherum kommt. Allerdings hat das nun nicht mehr viel mit der µC Programmierung zu tun an die der Großteil hier bei Nennung der Tätigkeit denkt. Die Programmierung am PC ist schon deutlich ähnlicher. Dazu kommt dann noch das wie oben angedeutet das auch keine µC Systeme im engsten Wortsinn mehr sind, da mindestens der Speicher extern sein muss. Durch die Layoutvorgaben beim Anschluss des Speichers und alleine schon durch die Gehäuseformen/PinCount der Bausteine selbst ist auch der Selbstbau alles andere als Einfach. Er werden einige Anforderungen ans LAyout gestellt, Lochraster, fliegende Verdrahtung oder gar Breedboard sind völlig Unvorstellbar. Bei einigen Bausteinen ist zudem 4Layer oder gar 6Layer Layout Pflicht. Für erste Schritte ist allemal ein Fertiges Dev.Board angesagt, evtl. geht auch ein "Zweckemdfremdetes" Industrieprodukt wie die Seagate Dockstar oder zum Beispiel einige Oszilloskope. Für spätere Einzelentwicklungen ist es dann teilweise deutlich billiger ein fertiges Prozessormodul zu kaufen als sich eine 4Layer Platine fertigen zu lassen. Dafür bekommt man schon locker mal 10 "normale" µC! Wo die 32Bit µC wie PIC32 oder CortexM3 für Schritte wie LED Blinken schon die "Kanonen" bei der Spatzenjagt" sind, da stellen Linux basierende Entwicklungssysteme dann den Father of all Bombs (FAOB / größte thermobare Bombe) dar. Solange keine Videobearbeitung, größere Grafikbearbeitung oder umfangreiche Signalanalyse geplant ist würde ich ohne andere besondere Anforderungen (wie Multitasking) daran keinen GEdanken verschwenden. Als Hobbybastler der nur ein wenig mehr in die Welt der Mikrocontroller eintauchen will schon gar nicht! Gerade als solcher ist man mit den AVR oder PIC Mikrocontrollern schon recht gut bedient. Wobei ich halt die "zentrale" Bereitstellung von Libs durch den Hersteller wie bei Microchip gegenüber der dezentralen durch viele verschiedene Hobbynutzer eindeutig bevorzuge. Aber das ist Geschmackssache. Es hat halt für mich den Vorteil eines immer recht einheitlichen Aufbaus und einer immer gleichen Rechtslage bei VErwendung, sowohl als reine Bastellei wie auch in komerziellen Produkten. (als reiner Bastler für Eigenbedarf ist zumindest die Lizenzfrage aber sowieso recht uninteressant, das gestattet wohl so gut wie jeder der seine Libs online stellt kostenlos) Und halt das, was ich als weiteren Vorteil sehe, ich mit derselben recht kostengünstigen Hardware sowie dem KOMPLETT vom HErsteller bereitgestellten Softwarepaket für Windows UND Linux ALLE Familien von 8Bit bis 32Bit problemlos ohne Zusatzaufwand je nach Bedarf bearbeiten kann. Aber auch das ist eine rine Geschmacksfrage! Gruß Carsten
Einsteiger mit Pause schrieb: > Nun zu meiner Frage: > Hab irgendwo gelesen, dass sich die PIC 32 "angenehmer" programmieren > lassen. Das halte ich für eine dreiste Lüge. Guck dir mal ein Stück MIPS-Assemblerprogramm an und du wirst dich nach deinem PI18 sehnen. Ja, für Leute, die immer nur in C programmieren und für die Hardwarezugriffe eine Treiberlib voraussetzen, ist das alles sicherlich völlig egal, aber das nur am Rande. Wenn du mal vorab die Nase in eine MIPS-Maschine stecken willst, dann lies mal das: Beitrag "Pollin MOTOROLA VIP1710" oder das: Beitrag "Pollin - Receiver-Mainboard mit Twin DVB-[T,C] Tuner, NXP PNX8950EH" Sind beides MIPS-Maschinen, beide mit nem Teil-Betriebssystem drauf und beideeklig, wenn man tatsächlich in den Gedärmen wühlen muß. W.S.
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.