Hallo, nach paar jahren programmierung auf Pic, hab ich mir gedacht mal die AVRs anzuschauen. auf den ersten Blick scheinen die AVRs wirklich besser, wenn man den Preis vergleicht. doch die Pics scheinen mir wesentlich praktischer - vorallem im anbetracht der Software die für Pic existiert. Ich programmiere immer in C. nun habe ich mich nach einem effizienten C-Compiler umgeschaut, der einfach ins AVRstudio eingebunden werden kann (bei Pic habe ich den C-Compiler von CCSC eingebunden in MPLAB)... den einzigen den ich gefunden habe, der einbindbar ist, ist WinAVR - aber jeder der mal mit einem professionellen C-Compiler programmiert hat wird sich mit WinAVR nur ärgern (ich erwähne hier nur mal die funktion _delay_ms() usw. - muss ich da etwa eine eigene delay funktion konstruieren?! ne das kanns nicht sein ). Da ich es nicht notwendig habe in der Programmierung Zeit zu verschwenden und weiss nicht was zu beachten (weil dies und das im C-Compiler nicht beachtet wurde oder unlogisch funktioniert) oder ständig zwischen zwei Software zu zappen, brauche ich dringend eine Lösung.. wer kein guru werden möchte, bzw. alle möglichen fehlerquellen zu umgehen weiss - der ist mit PIC was Software betrifft, besser bedient. (auch wenn es mehr kostet) ich revidiere meine Meinung, sobald jemand mir ein ebenbürtiger C-Compiler (einbindbar) zeigen kann (Preis spielt keine Rolle)... grüsse
Ist das der Versuch, einen Flamewar zu starten? Dabei ist doch noch gar nicht Freitag. <°)=====X
Wenn der Preis keine Rolle spielt, dann kauf dir 'nen IAR.
@Pierre: Also so professionell kannst du ja nicht sein, wenn du nicht zwischen C-Compiler und Library unterscheiden kannst. Niemand zwingt dich, die avr-libc zu benutzen. Sprichst du also vom Compiler oder von irgendwelchen Bibliotheken?
ich hab nicht gesagt ich sei professionell, sondern der C-Compiler. Ein kleiner Unterschied ;) .... und wenn du da mit library und so kommst ... bitte nicht verkomplizieren! ich will ganz einfach, ein C-Compiler in AVR-Studio einbinden, der aber auch was taugt... der C-Compiler von Winavr oder weiss ich was da für ein freeware Compiler ist... ist nicht so toll wie der CCSC (für Pic)..... wiegesagt bin kein guru .. und ich mag es nicht kompliziert! es muss einfach funktionieren - das aber gut und schnell... ähnlich wie es mit Apple und deren software funktioniert und nicht wie bei Windows, wo ab und zu mal was einfriert und sonstiger blödsinn - aber dies nur als ein weithergeholten Vergleich. Den IAR habe ich mir schon angeschaut ... bzw. die evalution Version - doch wie lässt sich der einfach ins AVRStudio einbinden? brauchts da noch Plugins?!
apropo zwingen, ich bin gezwungen WinAVR und was dazugehört zu verwenden, wenn ich AVR's mit der C-Sprache programmieren will...wenn ich keinen anderen einbindbaren C-compiler fürs AVRStudio finde... und das ist Übel... aber ich glaube es gibt schon was, nur kenne ich es nicht...
wie macht ihr es den? habt ihr eine software zum programmieren, die andere fürs Brennen?
soweit ich das weis hat der iar doch seine eigene ide mit dabei... naja aufjeden fall ist der avr-gcc (der compiler im winavr-package) de facto ein netter spross der gcc-familie und damit einer (wenn nicht sogar DER ) professionellsten compiler dies gibt ;) lad dir mal xcode von apple runter und du wirst den gcc bekommen g das was du suchst ist ne lib und ne ide... eclipse soll gut sein... gibts hier irgendwo ein nettes einrichtungs-howto verlinkt über den avr-gcc artikel wenn ich mich nicht irre... ich nehm geany zum programmieren.. ein shortcut startet mir den ein nettes make und das wars... es klingt zwar verlockend ala visual-studio alles zusammenzuklicken und dann hoffen das compiler und linker wissen was sie tun aber eine makefile ist einfach die kopfschmerzfreiere methode ;) gib dem system mal eine chance und du wirst sehen warum sich das ganze durchgesetzt hat auch wenns komplizierter ausschaut als andere lösungen ;) das ist so wie word und tex... die einen lieben tex die anderen haben nur keine ahnung davon g 73
Also Programmieren und "muss einfach funktionieren" ist eine seltsame Kombination. Und nochmal: Wie du einen Compiler in eine IDE einbindest und welche Libraries du benutzt - das sind numal 2 völlig verschiedene Sachen. AVR-GCC läuft auf problemlos ohne die AVR-LIBC und es gibt natürlich andere Bibliotheken. Und das hat nichts mit "Guru" zu tun, das sind eher die C-Grundlagen.
Vielleicht sucht der Herr Pierre ein Tool, wo man eben ins Mikrofon sagt, was das Programm so in etwa können muß, und rumsbums zack ist alles fertig im Controller drin. Das ist dann ganz einfach und man muß sich nicht mit häßlichen Delays rumärgern, die ja mit nem Timer viel schöner wären...
"AVR-GCC läuft auf problemlos ohne die AVR-LIBC und es gibt natürlich andere Bibliotheken. Und das hat nichts mit "Guru" zu tun, das sind eher die C-Grundlagen." andere bibliotheken..naja und welche sind effizient ... und betreff AVR-LIBC, ich will nicht z.b für delay, eine eigene funktion ausdenken, möchte lieber das ganze direkt verwenden... also c-compiler mit dazugehörigen libraries die auch korrekte funktionen enthalten... und die eingebauten delayfunktionen von AVR-Libc funktionieren nicht so ganz (falsche zeiten) => avr/delay.h) ...aber ja egal - ist IAR nun irgendwie einbindbar ins AVRSTudio?
@Doktor Lustig, ich suche was das RUMBUMS ZACK so funktioniert, wie ich es von PIC (Microchip) gewöhnt war. Ist das so schwer??
delay ist eben keine standard C-Funktion, und jede Bibliothek kann das irgend etwas anders anbieten.
nimm basic.. dann ist der code warscheinlich so effizient wie bei deinem pic-c-compiler... der gcc ist suppi.. wenn falsche zeiten beim delay rauskommen hast du warscheinlich die funktion falsch verwendet... und das programmers-notepad von winavr ist doch auch nett... für was brauchst du dann das komische avr-studio... und das kann mit dem/der avr-gcc wunderbar umgehn (angeblich... ich hab linux) und damit ist jedes problem beseitigt.. das ist nämlich der wunderwuzi-compiler... fast schon eine eierlegende wollmilchsau.. kann immerhin c,c++ und ada ;) 73
Aussagen wie "das ist effizienter als das" mag ich garnicht. Da werden manchmal die seltsamsten Sachen verglichen um den eigenen Standpunkt zu untermauern. Mit einer praktischen Anwendung hat das oft nichts zu tun. Eine delay-Routine ist übrigens nie sonderlich effizient ;) Ausserdem funktionieren die _delay_* Routinen in der AVR-LIBC. Der "_" am Anfang zeigt aber, dass es keine "idiotensicheren" Sachen sind, sondern diese Funktionen intern benutzt werden (ist auch ein Namensstandard, an den sich C-Programmierer normalerweise halten sollten). Um sie selbst zu nutzen muss man dann die Internals verstehen. Dazu muss man halt die Manuals lesen. Steht genau beschrieben. Die meisten Funktionen haben übrigens kein "_" davor. Sonst gibt es z.B. die Procyon Library: http://hubbard.engr.scu.edu/avr/avrlib/
@Pierre: wenn Du den IAR komplett kaufst, dann brauchst Du kein AVR-Studio mehr. Ist alles enthalten. ( Preis etwa 3000 EUR netto )
@Hans, interessant... thx für die infos... also wenn ich es weiterhin mit avr-gcc und der Ide von AVRstudio versuchen soll... dann möchte zuerst mal gerne wisse, wie programmierst du ein einfaches delay? von z.B 105us ohne die verschwendung eines timers... ein Ansatz würde mir genügen... also alles was in der avr/delay.h ist, funktioniert nicht korrekt. muss ich jetzt echt, mehrere Assembler Nops einfügen, mit loops kombinieren, ausrechnen wieviel zeit jeder einzelne befehl braucht und dann mit dem oszilloskop messen und die berechnung die nicht stimmen wird, korrigieren...bzw. probieren bis die zeit genau stimmt... geil nicht? ich habe einen externen Quarz à 16MHz..
>>Ist das so schwer?? Nein, ist nicht Einige stört nur das du so abwertend über avr-gcc, avr-libc schreibst. Wie wäre es einfach nur nach so was wie ccsc (oder wie heiss das komische Ding könnte ich sagen) nur für AVR zufragen ohne gleich WinAVR zu beschimpfen.
"muss ich jetzt echt, mehrere Assembler Nops einfügen, mit loops kombinieren, ausrechnen wieviel zeit jeder einzelne befehl braucht und dann mit dem oszilloskop messen und die berechnung die nicht stimmen wird, korrigieren...bzw. probieren bis die zeit genau stimmt... geil nicht?" Musst du nicht, aber du musst dem Compiler irgendwo mitteilen, was für einen Quarz du hast, falls du das noch nicht gemacht hast. http://www.nongnu.org/avr-libc/user-manual/group__util__delay.html
Nuja - ich hatte als blutiger Anfänger auch so meine Einstiegsschwierigkeiten. Aber inzwischen bin ich sehr zufrieden mit dem GCC. Ich benutze übrigens das AVRStudio überhaupt nicht, sondern Programmers Notepad in Kombination mit Ponyprog. Mit den entsprechenden Shortcuts ist compilieren und programmieren eine Frage von zwei Tastendrücken, für die makefiles gibts ein mitgeliefertes Tool, bei dem man sich die Features zusammenklicken kann. Bei jedem neuen System ist die Bedienung etwas anders und man muss sich erst einmal reinfuchsen. Mir würde höchstwahrscheinlich CSCC mit MPLab umständlich vorkommen. Wenn Du Dich mit den PICs gut auskennst und auch schon das Equipment zu Hause hast, sehe ich keinen Grund, das zu ändern - bleib dabei. Ein Wechsel kostet so oder so Zeit.
Mist, wollte eigentlich schreiben "wie schnell dein Quarz ist" In deinem Fall also #define F_CPU 16000000 Falls du irgendwo in deinem Programm schon ein F_CPU define hast und es trotzdem nicht klappt, kann es daran liegen, dass es schon im Makefile mit einem anderen Wert definiert wurde und das makefile hat soweit ich weiss Vorrang...
"dass es keine "idiotensicheren" Sachen sind, sondern diese Funktionen intern benutzt werden (ist auch ein Namensstandard, an den sich C-Programmierer normalerweise halten sollten). Um sie selbst zu nutzen muss man dann die Internals verstehen. Dazu muss man halt die Manuals lesen. Steht genau beschrieben." und wie komme ich zu einer idiotensichere Sache? zurück zu Pic? :P ... najooo nein das nicht, aber dann muss ich mich halt einarbeiten, studieren... oder die delayfunktion selber machen, messen probieren... @Hans "nimm basic.. dann ist der code warscheinlich so effizient wie bei deinem pic-c-compiler..." klar, kennst du den c-compiler? hast du schonmal ein programm für pic mit dem c-compiler geschrieben bzw. kompiliert und probiert? ... ich glaube nicht das du die Software von CCSC kennst ... also das war von A-Z eine Behauptung!! und übrigens, Pic ist gar nicht so schlechter wie viele behaupten: die A/D Wandler z.B im Pic sind wesentlich schneller... was einfach schlecht ist, sind die Preise.. aber nur als beispiel: findet mir mal nen 28beinigen uC mit 16K Flash ... aber klar vom Preis her, sind AVR's klar im Vorteil... 3000 EUR?!! also ich denke hier an max. 300EUR für ein Compiler - vorallem hab ich die IDE schon vorallem funktioniert mein USB-ISP Programmer mit AVR-Studio... also brauch ich nur den C-Compiler... aber ist schon klar... AVR-GCC ist gut - aber es gibt mehrere mögliche funktionen für ein "problem"...
@rms Und delay*() macht langsam... und wie programmierst du dann verzögerungen, bestimmte wartezeiten ohne timer?
also es gibt etwas das nennt sich "GCC-AVR Inline Assembler Cookbook" google findet das sofort.. da kann man folgendes rauskopieren...
1 | void delay(uint8_t ms) |
2 | {
|
3 | uint16_t cnt; |
4 | asm volatile( |
5 | "\n" |
6 | "L_dl1%=:" "\n\t" |
7 | "mov %A0, %A2" "\n\t" |
8 | "mov %B0, %B2" "\n" |
9 | "L_dl2%=:" "\n\t" |
10 | "sbiw %A0, 1" "\n\t" |
11 | "brne L_dl2%=" "\n\t" |
12 | "dec %1" "\n\t" |
13 | "brne L_dl1%=" "\n\t" |
14 | : "=&w" (cnt) |
15 | : "r" (ms), "r" (delay_count) |
16 | );
|
17 | }
|
The purpose of this function is to delay the program execution by a specified number of milliseconds, using a counting loop. The global 16 bit variable delay_count must contain the CPU clock frequency in Hertz divided by 4000 and must have been set before calling this routine for the first time.
Du könntest Dich eine halbe Stunde lang damit beschäftigen, selbst rauszufinden, was nötig ist, damit die Delay-Funktion aus delay.h funktioniert, länger dauert das nämlich nicht. Dabei lernt man nebenbei auch etwas C, zum Beispiel, daß man die Konstante F_CPU besser mit dem Suffix UL schreiben sollte ... oder aber Du erzählst weiterhin wirres Zeug. Und lernst nichts dazu.
>>von z.B 105us für AVR Libc version 1.4.4 <c>#define F_CPU 16000000UL /*16MHz*/ #include <util/delay.h> ....... /*105us*/ _delay_us(40); _delay_us(40); _delay_us(25); .....</c> Wo steht es das _delay_us einen Timer verwendet?
@Nik Bamert ... das mit F_CPU hab ich schon versucht, doch müsste ich demnach doch die definition in delay.h löschen.... njä.. wieso sollte übrigens eine delayfunktion langsam sein? scheisse wirds glaubs wenn in einer delayfunktion eine möglicher interrupt kommen sollte... und nach dem interrupt sollte das ganze wieder zurück zur delayfunktion springen wo es aufgehört hat....
> also alles was in der avr/delay.h ist, funktioniert nicht korrekt. Es funktioniert so wie beschrieben. Wenn nicht, dann schreib bitte einen Bugreport. Teil der Beschreibung sind übrigens die Grenzen dieser Funktionen sowie die Tatsache, dass sie nur mit eingeschalteter Optimierung vernünftig funktionieren. Letzteres ist dem Fakt geschuldet, dass sie zur Verbesserung des Komforts für die Benutzer zur Compilezeit mit Gleitkommazahlen arbeiten (damit kannst du eben auch 20.5 ms Verzögerung auswählen in der Granularität, die dein Prozessortakt erlaubt), dass aber nur eine eingeschaltete Optimierung es erlaubt, dass diese Gleitkommarechnung auch wirklich nur zur Compilezeit erfolgt und aus dem AVR-Code selbst eliminiert wird. Leider kommt das GCC-Plugin vom AVR Studio mit ausgeschalteter Optimierung als Default daher. Darüber beschwere dich bitte bei den Autoren von AVR Studio. Bedenke aber, dass sie das wohl auch nicht völlig aus freien Stücken so getan haben: das Debuggen von optimiertem Code (egal von welchem Compiler) ist gewöhnungsbe- dürftig, da der generierte Maschinencode nicht mehr so 1:1 zum C-Code passt, wie sich das der Programmierer auf den ersten Blick vorstellt. Da springt der Cursor schon mal hin und her zwischen den C-Zeilen, und bestimmte Hilfskonstrukte, die für die Gedanken- welt des Programmierers wichtig waren, waren dem Compiler dann einfach völlig unwichtig, sodass er sie komplett eliminiert hat. Wenn dich das stört, kannst du immer noch die low-level-delay- Funktionen ,,zu Fuß'' benutzen (_delay_loop_1 und _delay_loop_2) und dir die Zyklenzahlen selbst ausrechnen. Dann ist der Optimierungsgrad egal, die Zyklen musst du trotzdem nicht zählen, das haben andere schon für dich getan. > von z.B 105us ohne die verschwendung eines timers... Nun, die meisten Leute werden das Verbrennen von CPU-Zyklen wohl eher als Verschwendung ansehen als die Benutzung eines Timers. > 3000 EUR?!! also ich denke hier an max. 300EUR für ein Compiler Oh, du schrobst aber oben was ganz anderes, nämlich "Geld spielt keine Rolle". Preise in dieser Region sind das, was ordentliche kommerzielle Compiler halt kosten. Nicht, dass ich den IAR sonderlich leiden könnte, aber der von ihm erzeugte Code ist gut. Ob er das Geld wert ist, muss $KUNDE entscheiden. (Für mich ist wäre er es schon deshalb nicht wert, weil ich mich dann noch mit Windows rumschlagen müsste.) EUR 300 sind Peanuts. Dafür bekommst du vielleicht 'ne geile IDE, aber keine Compilerentwicklung bezahlt.
"scheisse wirds glaubs wenn in einer delayfunktion eine möglicher interrupt kommen sollte... und nach dem interrupt sollte das ganze wieder zurück zur delayfunktion springen wo es aufgehört hat...." Naja, aber diese Überlegungen haben ja erstmal primär nicht direkt was mit dem nutzenden Compiler zu tun, sondern mit grundsätzlichen Architektur-Fragen (Hardware und Software)
> Naja, aber diese Überlegungen haben ja erstmal primär nicht direkt > was mit dem nutzenden Compiler zu tun, sondern mit grundsätzlichen > Architektur-Fragen (Hardware und Software) Ach, das macht ein richtiger Compiler nicht von selbst? >:-)
> Ich verstehe die ganze Diskussion nicht. Bleib halt bei Deinem > PIC-Spielzeug dann. Dann könnte er ja aber hier gar nicht herumtrollen...
@Jörg das ist ja Quatsch. Pierre trollt nicht. er sucht sinnvolle Argumente / Belege, daß er den selben Komfort den er aus seiner PIC Welt kennt, auch in der AVR Welt vorfindet (vorzufinden hofft) Die bisher ihm bekannten Standard-Umgebungen bieten wohl nicht den gewohnten Komfort. Was ist da so schwierig, ihm ein paar Empfehlungen zu geben, anstelle gleich einen (in Grundeinstellung durchaus positiven) GAst in diesem Fohrum aus allen Rohren anzupissen? Macht das stark oder schön oder mutig, so auf einen "unwissenden" draufzuhauen?
> Macht das stark oder schön oder > mutig, so auf einen "unwissenden" draufzuhauen? Wenn jemand vollständig voreingenommen ist und lernunwillig (oder -unfähig) dazu, aber dennoch die Diskussion stets immer weiter treibt, dann ist das für mich auch Trollen. OK, ich wollte hier noch mehr schreiben, habe das aber jetzt besser gelöscht. Pierre sollte sich Eric Raymonds Artikel "How to ask smart questions" mal zu Gemüte führen. (Gibt's auch in deutsch.)
ich hätte anders fragen sollen, und nicht gleich was unterstellen: also nochmal anders: eine IDE (geeignet für alle Programmiergeräte) mit integriertem C-Compiler, also AVRStudio mit ? (avr-gcc plugin ist nicht so das wahre), bei PIC wäre es: MPLAB mit CCSC Compiler für 16F & 18Fxx... Preis max. 300
weiss das jemand so auf die schnelle? erkennt die IAR software jeden "normalen" Programmer (USB) ? ist das wirklich komplett? die limited version kostet sicher nicht 3000... mal guckn.
> eine IDE (geeignet für alle Programmiergeräte) mit integriertem > C-Compiler, also AVRStudio mit ? Wirst du nicht finden. ,,alle Programmiergeräte'', das ist ungefähr wie ein Schlüssel, der in alle Schlösser passt, egal wer wann wie das Schloss gebaut hat. Wenn du diese Restriktion wegfallen lässt, kannst du dir wohl die meisten kommerziellen AVR-Compiler angucken, da die alle mit ihrer eigenen IDE daherkommen. IAR hast du ja schon abgelehnt, dann gibt's noch Codevision und Imagecraft. Preise kenne ich nicht. Ansonsten: falsches Forum. Hier ist das GCC-Forum, warum erwartest du hier kompetente Antworten, obwohl du den GCC ja praktich von vornherein als tabu erklärst?
hm ich glaub avrstudio kann gar keine c-compiler integrieren, und hat nur den nicht optimierten gcc von grund auf inklusive.... nun mal ganz einfach ich hab von der firma icboard, den icprog version 2.0, möchte den gcc compiler verwenden (mit optimierung), in einer Software den Code schreiben und gleich kompilieren bzw. hexfile erzeugen. und von mir aus mit einer zweiten software den Usb icprog erkennen und mit dem das hexfile auf den avr brennen... was gibts das so für Lösungen?
Rowley Crossworks für AVR wäre garantiert auch keine Alternative, da steckt nämlich auch ein gcc drin, und wie wir dank Pierre wissen, kann der ja gar nicht funktionieren. Wie wäre es mit einem anderen Hobby? Briefmarkenzüchten oder Goldfischesammeln?
goldfischesammeln? wär mal was anderes :) ... gcc funktioniert sehr wohl..... nur habe ich keine geeignete umgebung dafür...
> hm ich glaub avrstudio kann gar keine c-compiler integrieren, > und hat nur den nicht optimierten gcc von grund auf inklusive.... AVR Studio hat gar keinen Compiler inklusive, sondern nur einen Assembler. Es kann andere Compiler integrieren, und bietet als Beispiellösung eine Integration des AVR-GCC an, wobei man sich den Compiler separat beschaffen muss (z. B. in Form einer WinAVR-Installation). Selbstverständlich kann ein GCC sehr wohl (und sehr gut) optimieren, nur dass AVR Studio das standard- mäßig nicht einschaltet (IAR's IDE aber zum Beispiel auch nicht). Was ein "Usb icprog" ist, musst du sicher erstmal erklären, es fällt wohl eher in eine der seltenen Kategorien, die nicht mehr unbedingt jeder kennt. Ich glaube, mit der Integration fremder Programmiersoftware tut sich AVR Studio aber ein bisschen schwer, die können nur die Atmel-Teile von Haus aus benutzen (STK500, AVRISP, JTAG ICE). Im Makefile eines WinAVR kannst du dagegen beliebige Programmer einbinden, sofern sie irgendwie ein Tool mitbringen, dem man über eine Kommandozeile den Download einer ihex- (oder M-Srecord-)Datei beibringen kann. Von Haus aus kommt mit WinAVR ein AVRDUDE mit, der ziemlich viele der gängigen Programmieradapter ansteuern kann.
IC-Prog ist ein Programmiergerät für AVRs, besprochen u.a. hier -> http://www.mikrocontroller.net/forum/read-1-215139.html . AVRProg (Bestandteil von AVR Studio) arbeitet damit sehr gut (eigene Erfahrung), man muss nut aufpassen, dass der serielle Port vom Programmiergerät einer von den ersten vier ist, andere erkennt AVRProg nicht. Wie Jörg schon erwähnte ist dies aber das GCC-Forum, das Thema gehört eigentlich ins "Mikrocontroller und Elektronik". Mit freundlichen Grüßen, ejd
icprog, sorry das ist nur der usb-dongle von www.icboard.de ... läuft mit avrstudio einwandfrei.... wie schalte ich aber die optimierung aus? und wie krieg ich den IAR-compiler in Avrstudio eingebunden? ich sehe da nirgends irgendeine möglichkeit compilier hinzuzufügen - im gegensatz zur IDE Software von Microchip (Pic) .
Im mittleren Preissegment gibt es noch andere C Compiler für AVR. Wenn man diesem Link http://www.atmanecl.com/EnglishSite/CompilerOverview.htm nachgeht findet man u.a.: DDS MICRO-C Developers Kits Trialversion vorhanden Kit: $ 99.95 US Super Developers Kit: $ 299.95 US http://www.dunfield.com/dks.htm C-AVR bzw. C-AVR-N 130-200 http://www.spjsystems.com/cavr.htm http://mitglied.lycos.de/Punesoft/ lcc-avr 0.2 Kostenlos, sieht aber arg verwaist aus http://www.xware.it/avr/ Zu Erfahrungen damit kann ich nichts schreiben; ich benutze WinAVR (d.h. AVR-GCC mit PN2 als IDE und AVRDUDE mit einem Parallelport-ISP) und kann hier nur die Links angeben. Bei der Suche nach den Links oben, ist mir übrigens der Spruch begegnet "Wer sucht denn C Compiler nach der IDE aus? Das wäre ja so, als ob man sich für sein Lieblingsbier nach dem Aussehen des Etiketts entscheidet." Zäumt man das Pferd richtig herum auf, helfen die Links zu diversen IDEs aus http://www.mikrocontroller.net/articles/Linksammlung#C
>>genau so hab ichs schon mal gemacht, >>stimmt aber nirgends... Stimmt nirgends, das ist etwas wage Was genau funktioniert nicht wie es soll. Und könntest du auch sagen welche Version von avr-gcc und avr-libc WinAVR verwendet?
die neueste softwware!...
hier der code:
#include <avr/io.h>
#define F_CPU 16000000UL /*16MHz*/
#include <util/delay.h>
void ini()
{
DDRD = 0x00; //PortD als Eingang
DDRC = 0xFF; //PortC als Ausgang
DDRB = 0x01;
PORTD = 0xFF; //Pullup
PORTC = 0x00;
PORTB = 0x06;
}
int main (void)
{
ini();
while(1)
{
PORTC |= (1 << PC1);
_delay_ms(200);
PORTC &= ~(1 << PC1);
_delay_ms(200);
}
return 0;
}
die delays sind aber viel viel kürzer - also völlig falsch!
_delay_ms(200) darf nicht sein. Schau in die Dokumentation von avr-libc(hier 1.4.4): http://www.nongnu.org/avr-libc/user-manual/index.html Hier direkt zu _delay_ms: http://www.nongnu.org/avr-libc/user-manual/group__util__delay.html#gd22e7a36b80e2f917324dc43a425e9d3 Der Parammeter von _delay_ms kann höstens 262.14 ms / F_CPU in MHz sein. Bei dir also 262.14 ms / 16 = ca. 17. Du muss es also z.B so lösen: for(i=0;i<21;i++) _delay_ms(10);
Das zweite Link geht nicht, weil das Forum hier zwischen 2 Unterstriche wie der hier _ ein <u> bzw </u> setzt. Das muss man im Browser-Adressleiste korrigieren.
@Martin, danke für die infos...doch die forschleife braucht auch paar nanosekunden an befehlszeit... macht zwar nichts aus, ist aber nicht haargenau... wenns z.B 100us sein soll, dann wirds mit dem delay und vorallem durch einbinden einer forschleife, ziemlich ungenau... werds probieren und mal ausmessen...
Du hast aber schon mitbekommen, daß diese for-Schleifenlösung nur für besonders lange Verzögerungszeiten (in Deinem Fall: länger als 17 msec) erforderlich ist? 100 µs ist deutlich kürzer als 17 ms ...
Wenn du ne Lampe genau blinken lassen willst nimm einfach nen Timer oder ne PWM. Kein normaler Mensch lässt sich delay-Zeiten > 10ms mit ner Warteschleife erzeugen, es sei denn er bekommt nicht einmal die Timer-Init hin. Für kurze delay-Zeiten (wie man sie z.B. für die 1-Wire-Timings braucht) sind die libc-Routinen brauchbar. Für deine große PIC-Erfahrung scheinst du wenig Ahnung vom Programmieren in der "Echtzeit" zu haben. Die wirkst eher wie ein Mensch aus der PC-Welt, dem sein Sleep(...) fehlt.
dann nimm halt die lustige funktion die ich oben als inline-asm gepostet hab.. die tut perfekt... im übrigen iar,... bringen ihre EIGENE IDE mit.. und dein programmer scheint ohne probs auch mit avrdude zu rennen... damit wär ich wieder bei meinem alten vorschlage.. eclipse oder programmers notepad... bei programmersnotepad dauerts unter 10klicks um make und avrdude in die ide zu integrieren... eclipse dürfte etwas aufwendiger sein.. beitet aber halt auch noch andere späße ;) 73
@Pierre, > scheisse wirds glaubs wenn in einer delayfunktion eine möglicher > interrupt kommen sollte... und nach dem interrupt sollte das ganze > wieder zurück zur delayfunktion springen wo es aufgehört hat.... > wenns z.B 100us sein soll, dann wirds mit dem delay und vorallem > durch einbinden einer forschleife, ziemlich ungenau... werds > probieren und mal ausmessen..." Dann hast Du wohl noch nie die Delayfunktion Deines PIC probiert. Delayfunktionen sind per se ungenau und nur zur Garantierung von Minimalzeiten geeignet. Jeder Interrupt und jede zusätzliche Schleife verlängert natürlich die Dauer. Und das ist absolut unabhängig von der Architektur bei PIC, 8051, AVR, ARM usw. immer der Fall ! Wenn Du das nicht haben willst, dann mußt Du einen Timer benutzen, Punkt ! > dann möchte zuerst mal gerne wisse, wie programmierst du ein > einfaches delay? von z.B 105us ohne die verschwendung eines > timers... ein Ansatz würde mir genügen..." Das ist Quatsch mit Soße. Die Timer sind für alle da, Delays benötigen keinen extra Timer. Der Trick ist einfach, einen Timer durchlaufen zu lassen, dann können ihn auch alle Prozesse benutzen (Tastenentprellung, Systemuhr, Multiplexanzeige, Delays, Scheduler, ...) Ein Delay-Beispiel mit Timer ist z.B. hier: http://www.mikrocontroller.net/forum/read-4-84831.html#new Peter P.S.: Und Delays mißt man nicht aus, sondern die läßt man gefälligst vom Präprozessor des Compilers berechnen. Dazu muß er aber die richtige Taktfrequenz der CPU wissen.
"Rowley Crossworks für AVR wäre garantiert auch keine Alternative, da steckt nämlich auch ein gcc drin" Nein, nur im Crossworks für ARM.
> aber nur als beispiel: findet mir mal nen 28beinigen uC mit 16K > Flash ATmega168.
@Pierre interessant ist für Dich vielleicht auch KAMAvr: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=27348 http://store.earthlcd.com/s.nl/it.I/id.317/.f?sc=14&category=-114 Es ist eine IDE für den GCC. Alles kostenlos, generiert das Makefile und proggt über den Dude. Völlig unkompliziert, bietet einen Haufen Leistung und kommt an die kommerziellen IDEs fast heran. Ansonsten, wie schon mal oben erwähnt, Codevision (130 Tacken glaube ich). http://www.hpinfotech.ro Bietet auch alles was das Herz begehrt und ist bitorientiert, ich meine damit z.B. PORTB.0=1 anstatt PORTB|=(1<<PB0) oder PORTB=0x01 Das bietet auch seine Reize. Grüße
Wenn Du unter 'professionellem Compiler' bzw. 'professioneller IDE' eine Software verstehst, die Dir einen großen Teil der Arbeit bereits abnimmt (was, wie andere schon angemerkt haben, eigentlich eher unprofessionell ist) und Du nicht mehr als 300 ausgeben willst, kannst Du ja CodeVision nehmen. Ist eine recht brauchbare IDE mit Compiler, der einige Embedded-spezifische Erweiterungen (oder sind es Einschränkungen?!?) enthält wie z.B. vereinfachte Bitzugriffe u.ä., kostet 150 netto inkl. 1 Jahr Support (Support-Verlängerung für 1 Jahr etwas mehr als die Hälfte), hat delay-Funktionen, die auch längere Zeiten können (das war ja glaub ich ein Hauptkritikpunkt deinerseits) und hat nen Code Generation Wizard, der Dir im Prinzip die komplette Initialisierung abnimmt und den Programmrumpf automatisch erstellt. Hat nur keinen eigenen Simulator, sondern nutzt den von AVRStudio. Außerdem gibts ne kostenlose Eval-Version mit Code Size Limit und ein paar weiteren Einschränkungen, die aber ansonsten auch ganz brauchbar ist. Ich habe meine ersten C-Programme für AVRs mit CodeVision geschrieben und bin eigentlich sehr zufrieden gewesen. Inzwischen bin ich allerdings auf AVRStudio/WINAVR umgestiegen, v.a. weils kostenlos ist und dabei sicher nicht weniger zu bieten hat als CodeVision. Für mich ist eigentlich der einzige größere Nachteil an WINAVR im Vergleich mit professionellen Systemen, dass es u.U. etwas dauert, bis neue Controller unterstützt werden. Das ist dann halt der Preis der Kostenlosigkeit. P.S.: Und Marc hat ja inzwischen während ich am tippen war auch den Link geliefert, so dass ich das jetzt nicht mehr tun muss.
Sorry, es sollte natürlich unten nicht "bei professionellen Systemen" heißen sondern "bei kommerziellen Systemen"
Vor 7 Jahren hatte ich auch mal mit CCSC gearbeitet. Ist ein "Compiler", der die Libs versteckt und dem Programmierer gut dokumentierte Schnittstellen zur Vergügüng stellt. D.h. man muss sich blindlinks auf diese versteckten Libs verlassen. Ein weiterer Nachteil war, dass die erworbene Lizens nur für 3 Monate oder so gültig war. Danach musste erneuert werden. Und wenn ich mich nicht irre, zum vollen Preis. D.h., sobald ein neuer Pic rauskam, war wieder eine Neu-Lizens faellig. Für Leute, die im semi-professionellen Bereich programmieren und denen die Pic-Architektur nicht zuwider ist, ist CCSC ein gute Lösüng. Aber es waere skuril, diesen "Compiler" mit GCC zu vergleichen.
>>wenns z.B 100us sein soll, dann wirds mit dem delay und vorallem...
Um möglichst genau 100us Verzögerung zu Programmierern kannst du auch
diese Funktion benutzen _delay_loop_2(uint16_t __count).
Für 100us bei 16MHz wäre das dann _delay_loop_2(1600).
Da werden höchstens ein paar Takte verschwendet.
Das der von dir gelobte ccsc macht das sicher nicht besser.
Ansonsten du bringst einiges durcheinander, wie kommst auf for schleife
bei 100us Verzögerung, ich habe deshalb for schleife verwendet weil es
200ms sein sollten.
Also Leute, ich finde diesen Thread und die Aussagen von Pierre eher belustigend. Als Beispiel: "...und wie krieg ich den IAR-compiler in Avrstudio eingebunden?.." Argh, verdammt, es wurde so oft gesagt hier in diesem verdammten Thema: Das IAR-Paket hat eine komplette IDE mit Compiler integriert. Da brauchst du nichts mehr in AVRStudio integrieren. Der IAR Compiler bietet dir auch sicher die Möglichkeit dein persönliches Kommandozeilenbasiertes Programmiertool einzubinden.
@Pierre: Ich verstehe nicht, was Du gegen Timer hast, wenn Du eine Delay-Funktion brauchst. Für soche Zeitgenauen aufgaben sind die Dinger doch da. Oder brauchst Du wirklich alle Timer des AVR für sontige Aufgaben? Gruß, Georg
ich hab mir vor kurzen das myAVRWorkpad PLUS zugelegt... das hat einen C
und Assembler Codewizard mit warteroutinen rechner und der ist ziemlich
päziese, dachte mal ich geb mein senf dazu hier mal ein beispiel:
Anforderung an den CodeWiz: Warteroutine 120 µs
hier der generierte C Code:
<c>
//--------------------------------------------------------------------
// Warte-Routine für 120 us
// die Routine wartet inclusive Aufruf 119,9 µs
// created by myAVR-CodeWizard
//--------------------------------------------------------------------
void myWait_120us()
{
_asm_ volatile (
"push r16\n"
"ldi r16,1\n"
"myWait_120us_3:\n"
"push r16\n"
"ldi r16,1\n"
"myWait_120us_2:\n"
"push r16\n"
"ldi r16,139\n"
"myWait_120us_1:\n"
"dec r16 \n"
"brne myWait_120us_1\n"
"pop r16 \n"
"dec r16 \n"
"brne myWait_120us_2\n"
"pop r16 \n"
"dec r16 \n"
"brne myWait_120us_3\n"
"pop r16 \n"
);
}
</c>
man kann sich auch delay_ms und delay_us mit parameterübergabe
generieren lassen... die delays vom WIN-AVR (avrlibc) haben mich auch
schon verzweifeln lassen :-(
gruß Jahn
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.