Als ich mal wieder über den erzeugten Asembler schaute, ist mir nun doch die Hutschnur geplatzt: WinAVR 20040404 avr-gcc.exe -dumpversion 3.3.2 if( (dc & 0x0800) == 0 ) 3d4: 93 ff sbrs r25, 3 MAX7219_PORT &= ~(1<<MAX7219_DO); 3d6: c1 98 cbi 0x18, 1 ; 24 WinAVR 20050214 avr-gcc.exe -dumpversion 3.4.3 3c8: 28 2f mov r18, r24 3ca: 39 2f mov r19, r25 ... 3d6: 61 e0 ldi r22, 0x01 ; 1 3d8: 70 e0 ldi r23, 0x00 ; 0 ... if( (dc & 0x0800) == 0 ) 3de: 93 2f mov r25, r19 3e0: 82 2f mov r24, r18 3e2: 89 2f mov r24, r25 3e4: 99 27 eor r25, r25 3e6: 86 95 lsr r24 3e8: 86 95 lsr r24 3ea: 86 95 lsr r24 3ec: 81 70 andi r24, 0x01 ; 1 3ee: 90 70 andi r25, 0x00 ; 0 3f0: 86 17 cp r24, r22 3f2: 97 07 cpc r25, r23 3f4: 09 f0 breq .+2 ; 0x3f8 MAX7219_PORT &= ~(1<<MAX7219_DO); 3f6: c1 98 cbi 0x18, 1 ; 24 Was soll denn das werden, die neue Version optimiert um Klassen schlechter als die alte ? Einfach mal so 30 Byte mehr für absolut nichts. Ich will mich ja nicht beschweren, aber sollten nicht neue Versionen mindestens gleichwertig sein. Naja, ich hab jedenfalls erstmal wieder die alte Version aktiviert, die hatte ja auch immer einwandfrei funktioniert. Man sollte eben nie grundlos updaten. Oder hat sich Atmel etwa beschwert, daß sie zu wenig ATMega128 verkaufen und zuviele ATMega8. Peter P.S.: Das Programm ist für nen ATTiny26 und da tun 1,5% Verschwendung pro Zeile schon richtig weh.
kannst mal ein größeres Codeschnipsel posten?
Ich hab auch gedacht, das der 4.01 schlechter optimiert, weil etwas
länger ausgesehen hat, aber wenn man die ganze Funktion betrachtet, war
es dann doch schneller.
Das zweite Assemblerlisting scheint mir aber nicht zum C zu passen.
Bei mir kommt raus (4.0.1 mit -O2):
245:ultraschall.c **** dantest (uint16_t dc)
246:ultraschall.c **** {
217 .LM15:
218 /* prologue: frame size=0 */
219 /* prologue end (size=0) */
247:ultraschall.c **** if ((dc & 0x0800) == 0)
221 .LM16:
222 0064 93FF sbrs r25,3
248:ultraschall.c **** PORTB &= ~_BV (1);
224 .LM17:
225 0066 C198 cbi 56-0x20,1
226 .L14:
227 0068 0895 ret
228 /* epilogue: frame size=0 */
229 /* epilogue: noreturn */
230 /* epilogue end (size=0) */
231 /* function dantest size 4 (4) */
P.S.: Ich würde auch sagen, daß WinAVR 20040404 einen Tick länger braucht zum compilieren, scheint also mehr zu machen (optimieren). Peter
Dass Winavr liebend gerne 16 für die ganzen Operationen nimmt ist ja bekannt. Und die ganzen Shifts habe ich ja auch schon beklagt... Wo wir schon beim Thema schlechte Optimierung sind: Ich habe eine Schleife in der steht in etwa *pointer++=werte (z.B. Eingangs Port oder ADC) In Assembler würde jeder den pointer Wert aus dem RAM laden, die Schleife durchlaufen, und den Wert am Ende der Schleife zurückschreiben. Der Compiler liest in jedem Schleifendurchlauf den Wert aus dem RAM, und schreibt ihn wieder zurück. Kann man das irgendwie wegoptimieren ? Ich dachte genau für sowas braucht man volatile, damit sooft wie möglich der RAM Inhalt aktualisiert wird. Ohne volatile sind die Aktualisierungen aber ungewünscht und nur lästig.
Ob er Register nimmt oder nicht, hängt davon ab, ob er noch welche frei hat und ob es ihm wichtig erscheint. Du kannst die Variable aber z.b. als "register uint8_t" deklarieren, dann nimmt er dafür eher ein Register. Bei welcher Optimierungsstufe hast du das beobachtet? Wenigstens -Os sollte schon sein. Ich schau mir meinen Code immer bei -O2 an, und da seh ich grad bei Schleifen dass er immer die Register nimmt. Noch ein Tip: Verwende wenn möglich immer lokale Variablen, die nimmt er besonders gern als Register, wobei er die Variable auch gerne mittendrin vergisst, wenn er sie später nicht mehr braucht und verwendet das selbe Register für eine andere Variable.
@Fritz, ich nehme immer -Os, bei -O2 ist der Code insgesamt noch größer, nur bei dem kleinen Ausschnitt im letzten Dateianhang gibt es keinen Unterschied. Hast Du ihn mal ausprobiert ? Du hast scheints ne noch neuere Version, als der WINAVR. Der Code scheint rein funktional noch richtig zu sein, aber eben 30 Bytes zu groß. Muß halt bloß noch überlegen, wie ich der alten Version den ATTiny2313 unterjubeln kann, den kennt sie nämlich noch nicht. Peter
Sieht bei mir gut aus, ich hab das .lst mal drangehängt. Ist mit -Os und gcc 4.01 für einen Tiny26 übersetzt.
Achja, natürlich gar kein WinAVR sondern unter Linux. Sollte aber am Ergebnis nix ändern. Windows ist doch nur zum zocken da, oder?
"Windows ist doch nur zum zocken da, oder?" Ich zocke nicht. Auf dem Firmenrechner ist XP installiert, basta. Wär ja auch Unsinn, teure Windows-Programme zu kaufen und dann Linux zu installieren. Ich bin auch nicht der Betriebssytem-Guru, d.h. auch mein Home-PC und Notebook sind fix und fertig mit XP vorinstalliert gewesen. Ich kann also nur GCC-Versionen benutzen, die als WINAVR verfügbar sind. Peter P.S.: Ich hatte mal die c't-Linux CD ins Notebook geschoben, Linux mag mein Notebook nicht. Auch sämtliche Dienstprogramme sind ja nur für Windows.
> Wär ja auch Unsinn, teure Windows-Programme zu kaufen Stimmt. > und dann Linux zu installieren. Ach so... :-)
> Ich kann also nur GCC-Versionen benutzen, die als WINAVR verfügbar > sind. Kannst du natürlich nicht, schließlich hast du dich erwiesenermaßen schon durch viel schlimmere Probleme hindurchgewurschtelt, aber es bietet die eben mal eine bequeme Ausrede. Selbstverständlich könntest du 1.) genauso gut wie alle anderen, die das bislang erfolgreich getan haben, einen GCC auch auf deinem Windows compilieren (da ist weniger Magie dabei als die Installation eines Windows selbst bietet) oder <flamebait> 2.) das Windows genauso gut in die Tonne kloppen -- aber dann wüsstest du vermutlich nichts mehr mit der ganzen danach frei gewordenen Zeit anzufangen, die dann nicht mehr fürs tägliche Händchenhalten von Windows draufgeht. :-) </flamebait> 99 % derjenigen, die heutzutage ein Linux oder NetBSD oder FreeBSD installieren, sind wohl eher nicht die, die sich als Betriebssystem- Gurus bezeichnen würden, sondern einfach reine Anwender... Bei FreeBSD könnte ich dir als Bonus bieten, dass ich die Ports der einzelnen Tools deutlich flexibler und damit schneller aktualisieren kann, als Eric das mit WinAVR möglich ist.
@Jörg, wenn der Leidensdruck groß genug ist, wird mir bestimmt ne Lösung einfallen. Da war ja hier kürzlich mal ne unoffizielle WINAVR Version, muß ich mal laden, wenn ich mal wieder Zugang zu ner Flatrate habe. Ansonsten kann ich nicht klagen über XP, läuft wie dumm und kommt auch beim Einschalten ordentlich schnell auf die Hufe. Auf den Firmenrechner habe ich aber keinerlei Einfluß, da muß XP laufen. Ich könnte höchstens im Exceed-Fenster auf der Sun Solaris laufen lassen. Peter
> Auf den Firmenrechner habe ich aber keinerlei Einfluß, da muß XP > laufen. Steter Tropfen höhlt den Stein. Es gibt wohl mittlerweile genug Firmen, in denen die einstige eiserne Policy, dass nur Rotberg- Weichware eingesetzt werden darf, gekippt worden ist. Ich könnte mir jedenfalls nicht vorstellen, meine Produktivität dauerhaft auf 50 % zu reduzieren, indem ich mir auf Arbeit freiwillig ein Windows antun muss.
wir schweifen zwar hier vom Thema ab, aber ich kann mich über Windows XP nicht beklagen. Es läuft alles einwandfrei. Warum soll ich mich auf Linux einlassen wenn mein Windows funktioniert? Warum soll ich in der Shell rumbasteln wenn ich mit klicken doppelt so schnell bin, vielleicht sogar dreifach? Was ist an FreeBSD/Linux besser als bei Windows? Der Preis ist halt unschlagbar aber das ist für mich kein Grund da ich Windows bereits besitze. Warum muss ich unter Linux bei Hardware Erweiterungen die Treiber so komliziert einbauen wenn unter Windows Plug&Play funktioniert? Mein Eindruck von Linux ist, dass ich mehr administriere als damit arbeite. Mit einem Betriebssystem auf dem PC will ich arbeiten und ich will nicht wissen wie es arbeitet. Ciao, Kai
> Warum soll ich mich auf Linux einlassen wenn mein Windows > funktioniert? Musst du nicht, aber ist eine von den Fragen, die ich sofort umdrehen könnte. > Warum soll ich in der Shell rumbasteln wenn ich mit klicken doppelt so > schnell bin, vielleicht sogar dreifach? Hier genauso. > Was ist an FreeBSD/Linux besser als bei Windows? Naja, für mich vor allem opensource, zusammen damit, dass ich Bill Gates nicht noch reicher machen muss. Aber noch viel mehr eben für mich das Arbeiten damit. Ich muss nicht 20mal für irgendwas klicken, wenn ich doch eigentlich ganz genau weiß, wie das gerade heißt und wo ich es im Dateisystem finde. > Warum muss ich unter Linux bei Hardware Erweiterungen die Treiber so > komliziert einbauen wenn unter Windows Plug&Play funktioniert? Weil PC-Hersteller nach wie vor nach der Methode arbeiten: ,,Windows geht damit (irgendwie, den Rest repariert sich der Endkunde oder der Händler), also raus damit, der Rest interessiert uns nicht!''? Weiß ich aber nicht. Ich musste bislang keine Treiber kompliziert in mein FreeBSD einbauen außer denen, die ich selbst für irgendwas geschrieben habe. > Mein Eindruck von Linux ist, dass ich mehr administriere als damit > arbeite. Mit einem Betriebssystem auf dem PC will ich arbeiten und > ich will nicht wissen wie es arbeitet. Genau das tu' ich mit meinen BSDs, Linuxen und Solarisen zu Hause und in verschiedenerlei Jobs (davon abgesehen, dass in den Jobs die Administration derselben oft Teil meines Jobs ist). Von Windows habe ich immer wieder den Eindruck, dass man damit viel zu viel herum,administrieren' (sprich: trial & error herumklicken) muss, bis es endlich das tut, was man will. Du siehst: die Argumente gleichen sich. ;-)
Wo Linux funzt ist es ne gute Sache. Es gibt aber noch genug Software, grad in der Industrie, die unter Linux gar nicht oder nur mit Tricksereien läuft. Dort fällt Linux schon aus dem Grund aus. Grüße T.M.
>> Warum soll ich in der Shell rumbasteln wenn ich mit klicken doppelt >> so schnell bin, vielleicht sogar dreifach? > Hier genauso. Richtig, weils von Unix kommt. Für mich deswegen auch nicht zufrieden stellent. Übrigens auch einer der Gründe warum sich nur wenige Leute unter Windows an das Thema heran trauen. Es ist schliesslich ein grosser Unterschied ob ich eine Auswahl an Paramtern per Fenster zu Gesicht bekomme und mich entscheiden kann oder ich tausenden Parameter in der Shell kennen muss ;-). An Windows ist das schöne, dass man nicht alles wissen muss, sondern das OS einen leitet (Ich lasse mich gerne leiten weil genau dies mir enorm Zeit spart). Als Beweis führe ich mich einmal auf. Ich bin totales Windowskind. Ich habe lange gebraucht um die Tool-Chain problemlos auf Windows erstellen zu können. Fakt ist aber, dass ich mit der Tool-Chain meine Zeit verschwenden will und nicht mit dem erstellen ;-). Arbeitsprinzip Unix: 0. 8 Std lesen wie das überhaupt geht. 1. Tool-Chain downloaden 2. entpacken 3. entarchivieren 4. configurieren 5. erste Fehlermeldung 6. 2 Std. später Problem gelöst. 7. compilieren 8. zweite Fehlermeldung 9. 3 Std später Problem gelöst. 10. endlich darf ich arbeiten (HURRA). Arbeitsprinzip Windows: 1. Knöpfchen drücken -> 5min warten (eben schnell nen Kaffe kochen) -> fertig 2. Arbeiten. Ciao, Kai
ps: Das Arbeitsprinzip von Unix welches oben steht gilt nicht für die Tool-Chain sondern für jeden Teil der Chain. 1. Binutils 2. GCC 3. LibC 4. ... as much as you want.
>Warum muss ich unter Linux bei Hardware Erweiterungen die Treiber so >komliziert einbauen wenn unter Windows Plug&Play funktioniert? Ja, das sind die Urban Legends... Es kann vorkommen, aber der Regelfall ist der: Gerät anschliessen, fertig. Beispiel in unserer Firma: USB-RS485 Konverter gekauft, unter Linux eingesteckt, und war sofort unter /dev/ttyUSB0 ansprechbar. Kein Treiber installieren, alles schon im Kernel (als Modul) vorhanden. Dann mit demselben zum Rechner auf der Anlage (XP). Windows will einen Treiber. Rechner hat aus Sicherheitsgründen kein Netzwerk und auch kein CD-ROM (mehr). Also CD-ROM einbauen, Treiber draufinstallieren. Eine Woche später, einen anderen Konverter, gleiches Produkt aber ein anderes Exemplar. Windows schreit nach einem Treiber. Und installiert eine neue COM-Schnittstelle... Ich kann mich nicht erinnern, dass ich in den letzten 2-3 Jahren einen Treiber für Linux irgendwie installieren musste. Ausnahme: der NVIDIA -Treiber. Da auch einfach runterladen, aufrufen, ein paar Mal Return drücken und fertig. Oder zu Hause: Acer Bluetooth Dongle eingesteckt, und konnte sofort vom Handy Daten zum Rechner senden. Nix installieren, sogar die BT Software wurde automatisch in die Iconleiste gepackt. Windows: Will eine Treiber-CD. Hab ich nicht mehr. Auf die Webseite von Acer: Da steht, man kann sie sich per Post schicken lassen, also muss man ein Formular ausfüllen um sie zugesendet zu bekommen. Hat man das ordentlich gemacht (mit den richtigen Adressdaten, man will die CD auch bekommen) gabs dann plötzlich doch einen Download-Link. Und die hatten meine Adresse. Gut, eine avr-Umgebung aufzubauen geht nicht mit klicken. Aber mit Copy & Paste aus der AVR-libc-Doku. Dafür in 10 Minuten (inklusive Download) mit der Compilerversion deiner Wahl gebaut. Mein Kollege hat von Linux Null Ahnung (von Windows auch nicht mehr), arbeitet aber seit 1 Jahr ohne Probleme damit.
> Arbeitsprinzip Unix: > 0. 8 Std lesen wie das überhaupt geht. ... > 10. endlich darf ich arbeiten (HURRA). Arbeitsprinzip Unix, wenn man statt einem AVR plötzlich einen MSP430 haben will: alles ganz genauso. Man ist in 15 Minuten fertig (je nach Geschwindigkeit des Downloads). Arbeitsprinzip Windows, wenn man plötzlich was Anderes haben will: man fängt alles von vorn an, bekommt einen anders mistigen Editor, der genauswenig für die Suppe taugt, alles ist komplett woanders, voller Einarbeitungsaufwand. > Arbeitsprinzip Windows: 1. Knöpfchen drücken -> 5min warten (eben > schnell nen Kaffe kochen) -> fertig Wenn's geht. Wenn nicht: finito. Keine Selbsthilfe möglich. ;-)
ich seh schon, hier treffen zwei Welten aufeinander. Ein sinnvolles Gespräch über den Bistr-O-Mat Antrieb würde ähnlich enden :-) Ciao, Kai
> Windows ist doch nur zum zocken da, oder?
Damit gehts wenigstens, bei Linux muß man vielleicht erst noch den
Kernel neu kompilieren; LOL.
> Damit gehts wenigstens, bei Linux muß man vielleicht erst noch den > Kernel neu kompilieren; LOL. Ja, und? Mach das mal bei Windows. ;-) Solange du den Kernel nicht selbst compilieren musst, sondern einen Compiler hast...
> Arbeitsprinzip Windows: > 1. Knöpfchen drücken -> 5min warten (eben schnell nen Kaffe > kochen) > -> fertig > 2. Arbeiten. http://diveintomark.org/archives/2003/08/04/xp
hmm, mir scheint einige Vorurteile wird Linux nie los. Es ist schon (die richtige Distribution vorausgesetzt) lange nicht mehr nötig irgendetwas selber zu kompillieren, aber es ist wenigstens möglich! aptitude install gcc-avr avr-libc und ich bin schon die erste Zeile C Code am tippen wenn der Windowsler gerade auf den Sourceforge Mirror weitergeleitet wird. Ich gebe gerne zu, dass Win2000 & XP gelungene Betriebssysteme sind, an den komfort eines Debian reichen sie aber nicht ran. Leider gibt es halt selbst im wissenschaftlich / technischem Bereich immer noch zu wenig Software für Linux, so ist mir zum beispiel kein brauchbarer Schaltungssimulator wie PSPICE für Linux bekannt. Matlab gibt es zwar, aber kaum Toolboxen. So bin ich im Moment gezwungen unter Windows zu arbeiten, weil es die "Embedded Target for Motorola MPC555" Toolbox nicht für Linux gibt. Mittlerweile hab ich mir sogar ne ganz brauchbare Arbeitsumgebung mit LaTeX und allem was man so braucht unter Windows zusammengebastelt, aber wenn ich dran denke das alles aktuell zu halten (aptitude upgrade)... Nur um verwendbare Matlab / Simulink Plots in EPS für meine Ausarbeitung zu erstellen muss ich immer noch Linux booten. Die nächste Windows Version wird übrigens einiges an Rechenpower für Online-Verschlüsselung verschlingen nur um den Benutzer beim richtigen Umgang mit seinen Multimedia Inhalten zu unterstützen. Tut mir leid, aber ein Betriebssystem in das so viel Entwicklung mich zu beschränken investiert wurde kommt bei mir nicht auf die Platte! Leider sehen die meißten das anders, denn sonst könnte MS sich sowas nicht leisten. Gruß, Thomas
> Arbeitsprinzip Windows: > 1. Knöpfchen drücken -> 5min warten (eben schnell nen Kaffe > kochen) > -> fertig > 2. Arbeiten. Hmm, stimmt wenn man 4MB RAM hat, ansonsten ist es wie Peter gesagt hat. Einschalten und los gehts mit der Arbeit. > Ja, und? Mach das mal bei Windows. ;-) Wozu sollte ich unter Windows ein Kernel kompilieren, läuft doch alles perfekt. > Die nächste Windows Version wird übrigens einiges an Rechenpower für > Online-Verschlüsselung verschlingen Ja, ein typisches Rechnersystem wird mit 2GB Arbeitsspeicher angegeben. Das halte ich nun wirklich etwas übertrieben. Aber wo wir gerade beim Speicher sind. Ich hatte ein Red Hat Linux mal auf nem PC mit 384MB RAM installiert. War ein Witz, die Kiste kam nicht in die Gänge. Für Windows XP null Problemo, die rannte wies Lottchen.
> Ich hatte ein Red Hat Linux mal auf nem PC mit 384MB RAM > installiert. War ein Witz, die Kiste kam nicht in die Gänge. Meine normale FreeBSD-Kiste zu Hause hat 512 MB, und auf der sind zwei Leute gleichzeitig mit voller grafischer Session eingeloggt (wie macht man das eigentlich bei Windows? ;-). Kein Problem. > so ist mir zum beispiel kein brauchbarer Schaltungssimulator wie > PSPICE für Linux bekannt. Das gute alte Spice selbst ist ein Unix-Programm.
Hallo ?! Mal eine kleine Frage : Warum kann nicht jeder das System nehmen, was ihm gefällt und womit sie zurecht kommt ?! Ich bin sicher ein Windows-User, der sich mit dem Ding auskennt und seine Strukturen da aufgebaut hat, kann genauso schnell, effektiv oder sonstewie arbeiten, wie ein Linux-/Unix- oder sonstwas User, der eine ähnliche Situation vorliegen hat. Muss man immer gleich Glaubenskriege vom Zaun brechen ?! Es sind doch alles Betriebssysteme und wenn diese halbwegs verbreitet sind, dann existieren doch bestimmt auch Lösungen. Alle Betriebssysteme haben spezifische Probleme und spezifische Vorteile. Wenn eines nur Nachteile hätte dann wäre es schon wirtschaftlich ausgestorben. Glaubenskriege (ob sie Betriebssysteme, Religionen oder Lebenseinstellungen betreffen) ist ungefähr so sinnlos, wie darüber zu diskutieren, ob Rechts- oder Linksverkehr besser ist. Mann geht mir das auf den Nerv - ich würde so was auch mal ausdiskutieren, aber nur wenn ich ein paar Bier dazu trinke und viel Zeit habe. So viel von mir, Daniel.
> Mann geht mir das auf den Nerv - ich würde so was auch mal > ausdiskutieren, aber nur wenn ich ein paar Bier dazu trinke und viel > Zeit habe. Prost! :-)
/* Ich bin sicher ein Windows-User, der sich mit dem Ding auskennt und seine Strukturen da aufgebaut hat, kann genauso schnell, effektiv oder sonstewie arbeiten, wie ein Linux-/Unix- oder sonstwas User, der eine ähnliche Situation vorliegen hat. */ Nein, ein Windows-User kann wesentlich schneller arbeiten.
Zum Wohl Jörg ! ;-) Hubert, willst Du Dich als Brandbeschleuniger betätigen oder bist Du so eine Art Forum-Anheiz-Elvira ?! Das wäre überhaupt mal eine Idee - man könnte so was wie flame-Anheiz-Programme schreiben. Das würde kaum eine merken ;-). MfG, Daniel
>Das gute alte Spice selbst ist ein Unix-Programm. Das ist mir schon bewusst, deshalb schrieb ich ja auch "brauchbar" ;) Ein "brauchbarer" Schaltungssimulator muss bei mir zumindest nen guten Schaltplaneditor, alle wichtigen Bauteile und ne konfigurierbare Simulationsanzeige mitbringen. >Warum kann nicht jeder das System nehmen, was ihm gefällt? hmm, zumindest hier im Thread hab ich noch keine Gewaltandrohung gelesen, dafür aber ne menge Beiträge von Leuten die genau das nehmen was ihnen gefällt und auch versuchen dieses zu begründen. >kann genauso schnell, effektiv oder sonstewie arbeiten klar, ich hab ja auch geschrieben, dass ichs mir ganz gemütlich unter Windows eingerichtet hab, aber versuch doch mal so ein System aktuell zu halten, unter Debian ist das nur ein Befehl, das nenn ich komfort! >Muss man immer gleich Glaubenskriege vom Zaun brechen ?! Bis jetzt verläuft diese Diskussion doch ganz sachlich, hat halt nur nichts mehr mit dem Thema zu tun. >Mann geht mir das auf den Nerv Du hast es aber trotzdem gelesen und dich sogar genötigt gefühlt dich hier einzuklinken. >aber nur wenn ich ein paar Bier dazu trinke und viel Zeit habe. Na dann, PROST! ;) 42, Thomas
Noch ein letzter Beitrag von mir: > Ein "brauchbarer" Schaltungssimulator muss bei mir zumindest nen > guten Schaltplaneditor [...] mitbringen. Du erwartest also einen gewissen Komfort. Genau das ist das Problem, Linux war nie komfortabel weil die Jungs (oder sehr viele), die es benutzen, auf ihr Terminal stehen und grundsätzlich Komandozeilenprogramme mögen; oder nicht? Deshalb wird es noch viele viele Jahre dauern, bis Linux ernsthaft an den Komfort von Windows herankommt. Eine echte Konkurenz braucht unser Bill in den nächsten 10 Jahren nicht zu fürchten.
Je nachdem was es für ein Programm ist.
Meine Linux-Navigationssoftware ist Klicki-Bunti, auch meine
Zugsteuerung.
Man kann sich die Konfiguration für Samba mit der Hand schreiben oder
sich per Klicki-Bunti zusammenklicken, geht beides.
Anderseits bräuchte ich ca. 10 Minuten um mit Excel usw. aus meiner
Messreihe die passende Grafik zu machen, in der Konsole ist das nur
ein
grep Erg x |awk '{ print $2, $3,$4,$5}'>data1;./plotting3 |gnuplot
d.h. einmal Cursor nach oben und Enter, schon ist die neue Grafik mit
den neuen Daten da.
Nun, ich hatte Stunden gebraucht um mit Protel 99 ein einigermaßen
brauchbares Layout zu erstellen. Nun beherrsche ich dieses Tool fast im
Schlaf und ich kann es bedienen ohne nachzudenken und ähnlich ist es
auch mit Excel. Wiederum würde ich ewig brauchen bis ich alle
Kommandozeilenschalter etc. im Kopf hätte :)
> grep Erg x |awk '{ print $2, $3,$4,$5}'>data1;./plotting3 |gnuplot
:)
In diesem Sinne, jedem das seine!
Macht's gut!
> Ein "brauchbarer" Schaltungssimulator muss bei mir zumindest nen > guten Schaltplaneditor [...] mitbringen. Warum das Bundle? Das ist doch genau das, woran viele Windows- Software (IMHO) krankt: das eigentliche Augenmerk der Entwickler lag z.B. auf dem C-Compiler, aber da jeder eine ,,IDE'' erwartet statt eines Compilers, wird ein mittelmäßig schlechter Editor mit gebundelt, mit dem man eher schlecht als recht arbeiten kann. GCC (um mal wieder on-topic zu werden :) ist der reine Compiler, mit einem geeigneten Editor zur Entwicklungsumgebung kann sich das dann jeder nach eigenem Geschmack einrichten. Ich würde ja nicht erwarten, dass jeder beim Anblick meines Emacs ,,Hurra!'' ruft, aber ich bin damit um eine Größenordnung schneller, als wenn ich z.B. die Arbeit mit AVR Studio machen müsste. (Ja, eine Größenordnung, das ist ernst gemeint.) Schaltplaneditoren gibt's doch einige, und die können mehr oder minder geschickt auch spice-Netzlisten ausgeben. Kommt noch der Aspekt dazu, dass man sich in einen Schaltplaneditor ohnehin gut einarbeiten muss, damit man damit flüssig arbeiten kann (wie letztlich bei allen CAD-Programmen), und da man einen solchen auch für die Platinenerstellung noch braucht -- warum nicht gleich einen derartigen (der dann gut ist und alles kann, was man braucht) dafür nutzen und die Simulation dranketten?
Die Trennung Capture/Simulator klingt ja in der Theorie ganz gut, aber bis ich unter Unix (in diesem Fall MacOS X) mit GSchem, Spice, gnuplot usw. dazu komme eine Schaltung zu simulieren habe ich mir zehnmal QemuX+Win98+SwitcherCAD installiert. Traurig, aber so erlebt. Ich bin mittlerweile manchmal *fast* schon am überlegen wieder auf Windows umzusteigen, da es so viele Software weder für MacOS noch für Linux gibt. Aber wahrscheinlich liegt das daran dass ich inzwischen viele der kleinen nervenden Probleme vergessen habe die den Alltag mit Windows zur Hölle machen. Mal sehn, vielleicht bekommt Microsoft das mit Longhorn ja hin.
Hallo Jörg, seh ich alles ganz genau so wie du, schön modular aufgebaut wäre natürlich das beste, wenn denn alle Komponenten auch perfekt zusammenarbeiten würden. Dann könnte sich jeder seine Umgebung selber zusammenstellen. Der eine nimmt halt GEDA, der andere den Kschem Part (fiktiv) und du emacs ;) und hinter den Kullissen läuft überall das gleiche. Aber so ist es nunmal leider nicht. Ich hab schon einiges unter Linux getestet (GEDA, Oregano, und irgendwelche KDE Sachen), aber nichts war so richtig integriert und alles riesen Baustellen wovon einige anscheinend schon nicht mehr weiterentwickelt werden. Und vor allem gibt es keine Bauteile, bis auf die idealen Standartkomponenten (R L C Diode Transistor). Ich will auch nicht für jede Simulation auf die Console wechseln müssen und meine Analysen per Kommandozeilenparameter könfigurieren. Hast du schon mal mit PSPICE gearbeitet? Ich meine, da leg ich einige Profile für meine Analysen an (Zeitbereich, Frequenzbereich, Parametric,...), simuliere und schau mir dann in aller Ruhe die Ergebnisse an, mache Berechnungen damit, lass mir villeicht nen Bode oder Nyquist Plot erstellen u.s.w. GCC ist natürlich vorbildlich in tausende Umgebungen integriert, ist ja auch die Grundlage von allem, aber ein ernsthaftes Equivalent zu PSPICE hab ich leider noch nicht gefunden (für Linux). P.S. Orcad ist auch nicht perfekt, Layout find ich grausam!
Ich bin der Ansicht dass die Benutzerfreundlichkeit unter Linux in vielen Bereichen Windows inzwischen überlegen ist. Als Beispiel wollte meine Schwester(16) auch gerne Linux (zusammen mit Windows 9x für Spiele) haben. Ok, Kubuntu CD eingelegt, partitioniert, noch drei mal Enter gedrückt, Benutzername mit Passwort ausgewählt einmal neu gestartet und nach dem Einloggen konnte sie los surfen. Einzig bei der Soundkarte war Handarbeit angesagt. Aber mit einer Step-by-Step Anleitung im Netz ging auch diese. Dos findet hingegen keine primäre Partition (fdisk* schon) und lässt sich somit nicht mehr installieren. Schon lustig wenn dass CD Laufwerk den Laufwerksbuchstaben "C" erhält... *fdisk: Plattengröße: 40GB, laut fdisk aber nur 12 GB. Dafür ist die Primäre Partition 2GB groß und belegt 5% der angeblichen 12GB... Ach und hier noch eine kleine Liste was bei mir (Debian seit gut einem Jahr) nicht geht: -Die Treiber von ATI (unter Knoppix aber schon) -Für Scanner des Netzwerk-multifunktionsgerätes gibt es keine Linuxtreiber Und das vermisse ich unter Linux: -Spiele -Mit Delphi vergleichbare Entwicklungsumgebung (Lazarus ist noch zu stark eine Beta) Was ich nicht vermisse: -Die Abstürze von Windows9x und die beleidigende Erklärung beim Scandisk danach man möge den PC doch bitte ordentlich herunterfahren. -die Treiberorgien für Netzwerk, Grafik, TV, SCSI, Sound, USB Stick, Kartenleser. -Die Neustarts -Den einzelnen Desktop -Die Neubelegung der Laufwerksbuchstaben von erweiterten Partitionen beim Einbau/Entfernen einer weiten Platte. -das plötzliche Wiederauftreten von Fehlern die man längst behoben glaubte -Das Hilfesystem bei welchem ich stets zu dem Punkt kam dass das Problem mit dem Ratgeber nicht lösbar sei.
. "Und das vermisse ich unter Linux: -Mit Delphi vergleichbare Entwicklungsumgebung" Von den Machern von Delphi höchstselbst: Kylix.
Die erste Kylix Version hatte ich damals mal ausprobiert. Was mich am meisten störte war, dass die fertigen Programme irgend welche Librarys benötigen, die auf normalen Rechnern nicht vorhanden sind. Wohingegen die mit Delphi erstellten Programme (mit WINE) fast alle problemlos funktionieren. Auch sonst fehlten einzelne Komponenten der Windows Version. Aber vielleicht sollte ich die aktuelle Version doch mal wieder ausprobieren eventuell hat sich da ja was gebessert.
> -Die Abstürze von Windows9x und die beleidigende Erklärung > beim Scandisk danach man möge den PC doch bitte ordentlich > herunterfahren. Abstürze unter XP gehören der Vergangenheit an. Ich benutze seit 2 Jahren XP und hatte eigentlich nur Abstürze beim ausprobieren eines selbst geschriebenen Kernelmode Treibers. > -die Treiberorgien für Netzwerk, Grafik, TV, SCSI, Sound, > USB Stick, Kartenleser. I. d. R. auch kein Problem unter XP. > -Den einzelnen Desktop Dafür gibt es Tools sogar von Microsoft, wenn man denn soetwas zwingend braucht. > -Die Neubelegung der Laufwerksbuchstaben von erweiterten > Partitionen beim Einbau/Entfernen einer weiten Platte. Dies ist in der Tat sehr nervig. > -Das Hilfesystem bei welchem ich stets zu dem Punkt kam > dass das Problem mit dem Ratgeber nicht lösbar sei. Unter XP ist die Hilfe sehr gut gelungen. Fazit: du solltest von Win9x Abstand nehmen, diese Systeme waren in der Tat nicht besonders gut.
> Ach und hier noch eine kleine Liste was bei mir (Debian seit gut > einem Jahr) nicht geht: > -Die Treiber von ATI (unter Knoppix aber schon) Das ist natürlich primär die Schuld von ATI. Die haben sich lange Zeit gar nicht um Linux gekümmert und hinken deshalb mit ihren Treibern gegenüber NVidia (*) weit hinterher. Da sie auch keine Informationen über die Programmierung der Hardware rausgeben, kann auch kein anderer vernünftige Treiber schreiben. * Die NVIdia-Treiber waren anfangs auch nicht so arg stabil, zumindest auf AMD-Systemen, sind aber seit einer ganzen Weile sehr gut und unterstützen auch bei 3D-Grafik alles, was die Karte hergibt. > -Für Scanner des Netzwerk-multifunktionsgerätes gibt es keine > Linuxtreiber Bei Sane ist nix dabei? > Und das vermisse ich unter Linux: > -Spiele Daran teilen sich die Spielehersteller und Microsoft die Schuld. Erstere, weil sie sich gößtenteils um Linux kaum kümmern, letzere, weil sie haufenweise APIs raushauen, die zu nix außer Windows kompatibel sind. Wenn die dann umfassend genutzt werden, wird die Portierung extrem erschwert. Und mit Longhorn wird's noch schlimmer, denn da hat Microsoft jetzt endlich einen Weg gefunden, OpenGL unter Windows nutzlos zu machen. Der Grund ist zwar hanebüchen, aber das hat Microsoft ja noch nie aufgehalten.
Naja den Spieleherstellern kann man keinen Vorwurf machen. Ich würde auch für das Betriebssystem entwickeln, das am meißten verbreitet ist. Linux ist nunmal nicht sehr weit verbreitet.
> Naja den Spieleherstellern kann man keinen Vorwurf machen. Ich > würde auch für das Betriebssystem entwickeln, das am meißten > verbreitet ist. Ich würde es so entwickeln, daß es mit möglichst plattformunabhängig ist und sich one große Änderungen auf beiden Systemen compilieren lässt. Daß das durchaus geht, sieht man an ID-Soft. Die haben seit eh und je ihre Spiele für Windows und Linux rausgebracht. Teilweise wurden die sogar unter Linux entwickelt und dann nach Windows portiert.
Sogar die amerikanische Armee schafft das, AAO gibts für Windows, Linux und Mac OSX.
Hi und es ist auch nicht wirklich schwierig wie Projekte wie http://www.ogre3d.org/ beweisen. Die 3D-Engine nutzt entweder auf openGL oder D3D unter diversen Betriebsystemen auf. Für ein paar simple Klassen die OS spezifische Dinge (Zeichenflächen, Benutzereingaben, Datei-Handling) abstrahieren dürfte nicht mehr als ein paar Manntage zu investieren sein. Aber wo kein Markt da keine Produkte und wo keine Produkte da kein Markt. Ist leider so, und M$ tut sein Möglichstes openGL soweit als möglich gegenüber D3D niederzuhalten. Matthias
Ich werfe einfach einmal ein paar Fische in die Runde an alle, die sich wieder an dem sinnlosen Flamewar beteiligt haben und will nun zur eigentlichen Frage zurückkommen: Welche Version von WinAVR kann man nun bedenkenlos einsetzen?
Keine. Oder die neueste. Oder was auch immer: guck dir doch an, was generiert wird.
Ja sicher könnte ich jetzt beginnen, alle Versionen seit ... nacheinander zu installieren und dann den erzeugten Code zu analysieren. Schade, dass ich im Moment die Zeit dazu nicht habe. :( Ich hatte gehofft, die Erfahrung hätte schon ein anderer gemacht und könnte mir (und anderen) sein Ergebnis mitteilen.
Also, wir fassen kurz zusammen - alle möglichen Versionen von WinAVR kann man bezgl. Funktion - also der generierte Code macht das, was programmiert wurde - bedenkenlos einsetzen. Welche Version eine gute und welche eine weniger gute Größenoptimierung ist nicht klar. Daneben scheint es immer angezeigt, die neueste freigegebene Version zu verwenden, da diese auf dem neuesten Stand ist, was Erweiterungen und Bugfixes angeht. Habe ich das so weit richtig verstanden ? Für den Hobby-Anwender wird das wahrscheinlich eh schnurz sein, ob die Größenoptimierung jetzt mal um 10 % rauf oder runter geht, da Hobby-Anwender eh meist wesentlich mehr Speicherplatz einplanen (zumindest sollten). Das ist ja auch kein Problem, wenn man seinen Code eben nicht mehr in einen ATmega16 hineinbekommt, dann nimmt man eben einen 32er. Ist ja egal, solange man keine Stückzahlen produziert. Blöde ist das natürlich, wenn man ein altes Projekt noch einmal aufbauen will und die Source kompiliert so groß, dass man die Hardware ändern muss. MfG, Daniel
> Blöde ist das natürlich, wenn man ein altes Projekt noch einmal > aufbauen will und die Source kompiliert so groß, dass man die > Hardware ändern muss. Eben, und was lernen wir daraus? WINAVR bzw. dessen Äquivalent für die Pinguinklickibuntiwelt ist definitiv nicht für professionelle Anwendungen geeignet sondern ist eher nur als Spielzeug anzusehen, welches aus dem Drang einiger Freaks entstand, die meinten, mal unbedingt was portieren zu müssen statt etwas mehr Zeit mit ihrer Familie zu verbringen.
Anscheinend im Heise-Forum nix los. Also, dann nehmen wir doch den guten und professionelen AVR-Compiler von Mikrosoft!
Gar nicht unmöglich, man kann durchaus die IDE von Visual C++ so konfigurieren, das sie mit AVR und WinAVR klar kommt, selbst der Debugger (AVR-Studio) läßt sich aus der IDE aufrufen. Selbst absolute MS-Ignoranten sollten wissen, daß der Editor nicht schlecht ist.
Gut, und welcher Compiler wird dann von der IDE aufgerufen? Wohl wieder dieser Hobby-Frickel-gcc. :-)
nein, du rufst einfach Dein normale make (und stellst dort Deinen Compiler ein) auf, wenn Du gut bist, dann läßt sich der Editor so konfigurieren, daß er auch zur Stelle im Code springt, wo zB. ein Syntaxfehler vorliegt.
Hi so toll ist der VS Editor auch wieder nicht. Da gibts in der OSS-Ecke durchaus vergleichbare. Mit dem Plugin VisualAssistX wird er aber zum Besten mit dem ich bisher gearbietet habe. Da kommt kein mir bekannter freier Editor dran. Leider kostet allein das Plugin knapp 100 Dollar. Matthias
Jo, VisualAssist 10 ist sein Geld wert, obwohl man die Tools auch alle einzeln bekommen oder selber machen kann. Ich habe das Teil sogar in der Firma durchsetzen können... Kleine Werbung, für die ich nix bezahlt bekomme: http://www.wholetomato.com/
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.