Hallo zusammen! Ich habe eine Schaltung entworfen, um meinen iPod über ein CAN-Interface zu steuern. Mit einem Arduino Mega2560 auf einem Breadboard funktioniert das auch wunderbar. Nun habe ich dafür einen eingenen Schaltplan entworfen (im Anhang), das Layout auf eine Platine gebracht und bestückt. Allerdings scheint der mega2560 nicht zu starten. Ich kann ihn mit einem ArduinoISP flashen (es wird geschrieben und auch gelesen, alles ohne Fehler). Allerdings zeigt weder mein Display was an, noch kann ich eine LED am Pin des mega einschalten. am SCL des I2C kann ich eine Rechtecksignal messen, zu mehr ist mein DSO150 wohl nicht fähig ;) Außerdem habe ich die ganze Platine mit dem Multimeter durchgepiept, konnte aber keine Fehler finden. 5V, 3.3V und auch die 2,9V und 2V am Spannungsteiler für den iPod sind gut, GND ist auch überall da, auf den Signalleitungen konnte ich weder Unterbrechungen noch Kurzschlüsse feststellen (Vor allem die I2C Leitungen für das Display hab ich mehrmals von vorne bis hinten durchgemessen). Zusammenfassung: - mega2560 lässt sich fehlerfrei flashen - Clocksignal an SCL ist da - geflashtes Programm läuft nicht Hat jemand eine Idee woran das liegen könnte? Hab ich was übersehen?
Angehängte Dateien:
-
lagunapod.png
40 KB
Den Wert von C1 solltest du noch mal überprüfen. Und ein Abblockkondensator gehört an jedes VCC-Gnd Pin-Pärchen. Was meinst du wohl, warum die paarweise nebeneinander liegen.
Hallo, wie (auf was) sind den die Fusebits des AVR gesetzt? Ich würde mir ein Testprogramm "Blink" mit 1Hz Blinkfrequenz schreiben und an einem Pin ausgeben..
2.3.17 AVCC AVCC is the supply voltage pin for Port F and the A/D Converter. It should be externally connected to VCC, even if the ADC is not used. If the ADC is used, it should be connected to VCC through a low-pass filter. AGND schwebt ebenso in der Luft und an AREF könnte man auch einen Kondensator vorsehen...
Wolfgang schrieb: > Den Wert von C1 solltest du noch mal überprüfen. > > Und ein Abblockkondensator gehört an jedes VCC-Gnd Pin-Pärchen. Was > meinst du wohl, warum die paarweise nebeneinander liegen. Die 22pF für C1 hatte ich aus dem Schaltplan des Arduino übernommen... Welchen Wert würdest du vorschlagen? In anderen Schaltplänen habe ich nun auch 100nF gesehen. Einen Kondensator an jedes Pärchen packen dürfte im Nachhinein jetzt etwas schwierig werden, aber ich werde das bei Gelegenheit testen ;) Testprogramm habe ich versucht - ohne Ergebnis. Fusebits weiß ich nicht - Ich hatte aber zuerst einen Arduino Bootloader geflasht, und den dann mit meinem Programm überschrieben. Beim Bootloader brennen sollte ja die IDE die Fusebits entsprechend setzen? Ich werde mal versuchen ob ich mit was anderem als der ArduinoIDE rankomme, WinAVR nimmt halt den ArduinoISP nicht... Edit: Arc Net Danke für den Hinweis - Das werde ich als erstes testen :)
:
Bearbeitet durch User
OK, AVCC und AGND sind mit VCC und GND verbunden, und C1 ist jetzt 100nF. Leider bringt das keine Veränderung... Die zusätzlichen Kondensatoren hab ich jetzt momentan noch nicht dran, ist mir heute zu fummelig ;) Aber vermutlich wird mir nichts anderes übrigbleiben, als das die tage zu testen...
Hi Ist der RESET-Pin vom ISP-Steckverbinder auch mit RESET vom Controller verbunden? MfG Spess
Die 22p an Reset bewirken nicht viel, wenn Du schon extern den Reset handeln willst, mindestens 100n. Sollte aber auch nichts bringen, der interne PowerOnReset des mega reicht als "reset-quelle". Kannst Du mal Dein Testprogramm posten? mfg
Sorry, hab grad gesehen, dass das schon geändert ist. Hast Du mal getestet, ob Deine Versorgungsspannung schwingt? 78xx neigen zum Schwingen ohne C's dicht am Ein- und Ausgang. mfg
J Zimmermann schrieb: > Die 22p an Reset bewirken nicht viel, wenn Du schon extern den Reset > handeln willst, mindestens 100n. Sollte aber auch nichts bringen, der > interne PowerOnReset des mega reicht als "reset-quelle". > Kannst Du mal Dein Testprogramm posten? > mfg Das heißt, ich dürfte den Kondensator auch einfach komplett weglassen und den Reset einfach mit den 10k auf HIGH ziehen? Das ursprüngliche Programm ist mein komplettes Programm das den ipod steuert und entsprechendes auf dem Display ausgibt. Nachdem das nix gebracht hat, hab ich ganz schlicht ein paar zeilen geschrieben das bei einem Tastendruck den PB0 auf high schaltet, und hab hier einfach eine led mit vorwiderstand (für 10mA) in den Header des CAN-Moduls gesteckt. Nichts weltbewegendes ;) Die Spannung sollte sauber sein, ich habe einen 7805sr drin, der müsste ja ohne zusätzliche C's klarkommen https://power.murata.com/data/power/dms-78xxsr.pdf
Angehängte Dateien:
-
2560.png
19 KB
Ich hatte schon ein ähnliches Problem. Bei einen 328p der startet zu schnell wo die Spannung noch zu instabil war was dazu führte das ich vor JEDEN Programm start den Reset noch mal selber auslösen musste. kann es sein das du die Abschaltspannung für den 2560 falsch gesetzt hast ?
DAVID -. schrieb: > kann es sein das du die Abschaltspannung für den 2560 falsch gesetzt > hast ? Kannst du deine Frage mal mit datenblattkompatiblen Begriffen formulieren. Wo besitzt der ATmega2560 irgendeine Abschaltspannung?
> Wo besitzt der ATmega2560 irgendeine Abschaltspannung?
BODLEVEL fuses (Brown-Out)
David, wie komme ich an die Einstellungen die du da auf dem Screenshot zeigst? ;) Einen Reset selbst auslösen bringt leider auch keine Änderung :(
:
Bearbeitet durch User
Hi, hatte mal ähnliche Start-Probleme bei Verwendung von DCDC-Wandlern zur Speisung von MAX7219, kannst Du evtl. den "digitalen" 7805 mal gegen einen "analogen" tauschen? Evtl. helfen könnte eine extreme Verlängerung des Resets, also 10k/1µF, oder die Brown-Out-Spannung auf den höchsten Level setzen, oder am Anfang des Programms ein "fettes" _delay. mfg
Ich hab noch ein bisschen rumgetestet. C1 am Reset hab ich komplett entfernt, sprich Reset ist jetzt über 10k an high. Den Spannungsregler hab ich entfernt, das ganze läuft jetzt nur noch über die Spannungsversorgung vom Programmer. Auch ein 5 sekündiges Delay am Anfang des sketches brachte nix. Testweise das Quarz ausgelötet, das führte nur dazu dass er sich nicht flashen lies. Bei jedem Schritt hab ich frisch geflasht und getestet. Kann evtl einfach der Mega selbst beim löten etwas abbekommen haben? Aber warum kann ich ihn dann problemlos beschreiben? Ach ja, ich hab jetzt einen ganz primitiven blink-sketch drauf, der PB4 ein und ausschaltet. An PB4 hab ich eine LED mit vorwiderstand gesteckt (das MAX2515 Modul wird ja nur gesteckt, somit ist der Pin-Header dafür offen, auch sind weder Display noch ipod eingesteckt. Selbst das Pegelwandler-Modul hab ich testweise rausgenommen...
:
Bearbeitet durch User
Stefanus F. schrieb: >> ich hab jetzt einen ganz primitiven blink-sketch drauf > > Und blinkt die LED? Nein, das ist ja mein Problem ;)
Da die ISP Schnittstelle funktioniert, sind offensichtlich alle Voraussetzungen geschaffen, dass der Mikrocontroller arbeiten kann. Zeige dein Blink-Programm, und die Einstellungen der Fuses. Auch auf die Gefahr hin, dass du jetzt Schnappatmung bekommst: Teste die LED! Manchmal sind Fehler nämlich so simpel, dass man nicht drauf kommt.
LED ist getestet - mehrmals ;) Direkt an der Spannungsversorgung des Anschlusses. Wie komme ich denn an die Fuses ran? Das Bild von DAVID zeigt ja einiges in der Arduino IDE, die Punkte gibts in meiner aber nicht. Als Programmer habe ich halt nur den ArduinoISP. Der Sketch ist ganz primitiv: #define PIN_LED PE4 void setup() { pinMode(PIN_LED, OUTPUT); } void loop() { digitalWrite(PIN_LED, HIGH); delay(500); digitalWrite(PIN_LED, LOW); delay(500); }
Bei 16 MHz bleibt nicht viel Auswahl für die Versorgungsspannung. BODLEVEL 2V7 ist nicht. Ansonsten steht deine Versorgung auf wackeligen Beinen. Im Arduino-Board ist z.B. ein 47u Bulk drinnen und bei dir hat der 7805 gar keine Kondensatoren. Vom 3V3-Regler verlangst du eine Dropout von 1,7V. Das passt nicht zur 78er Klasse. Zudem bietet es sich immer an, eine Mindestlast in Form einer LED einzubringen. Vielleicht stellt dein Programmer diese Mindeslast dar, und wenn er ab ist, gehen die Spannungen durch die Decke. Bei so vielen freien Pins hätte ich die Taster auf einen anderen Port gebracht und den JTAG vorgesehen.
Zeige deinen Aufbau! Auch wenn du es nicht glaubst, mit einem mickrigen Abblock- Kondensator wird dein Controller nicht funktionieren. Dazu kommt noch dass Vcc und Gnd "vernünftig" geroutet sein müssen. Das ist bei einem Arduino offensichtlich der Fall. Ob es bei deinem 256 so ist kann ich nicht beurteilen, jedoch kommen diese Gedanken bei mir auf nachdem ich die ganze Symptomatik mitverfolgt habe. Wir haben hier schon viele Layouts gesehen die diesbezüglich katastrophal waren.... Auch kannst du einen Lötfehler am Prozessor haben der das Ding nicht loslaufen lässt. Immerhin macht das Arduino-Framework einiges im Hintergrund bevor man mit dem Programmablauf zur main() gelangt. Dass du ihn scheinbar fehlerfrei flashen kannst muss kein Beweis sein dass der Controller auch sonst einwandfrei funktioniert. YMMV
Matthias G. schrieb: > C1 am Reset hab ich komplett entfernt, sprich Reset ist jetzt über 10k > an high. Das ist wohl möglich, aber kaum vernünftig. Das kann gut arbeiten nur, wenn Reset-Leitung nicht zu lang ist. Sonst bekommt man eine Antenne, die alle Störfelder herum nimmt. Wann reicht das für zufällige Reset, ist eine Lotterie. Würde es hier um viele € gehen, könnte ich diese Sparschaltung noch verstehen. Aber nur wegen 5 Cent-Kondensator...
Maxim B. schrieb: > Matthias G. schrieb: >> C1 am Reset hab ich komplett entfernt, sprich Reset ist jetzt über 10k >> an high. > > Das ist wohl möglich, aber kaum vernünftig. > Das kann gut arbeiten nur, wenn Reset-Leitung nicht zu lang ist. Sonst > bekommt man eine Antenne, die alle Störfelder herum nimmt. Wann reicht > das für zufällige Reset, ist eine Lotterie. > Würde es hier um viele € gehen, könnte ich diese Sparschaltung noch > verstehen. Aber nur wegen 5 Cent-Kondensator... Das erklär mal genauer. Wieso kann es zu zufälligen Resets kommen und wie kann der Kondensator das verhindern.
Bernard B. schrieb: >> Wo besitzt der ATmega2560 irgendeine Abschaltspannung? > > BODLEVEL fuses (Brown-Out) Der Brown-out Detektor löst eine Reset aus. Außer dem Reset-Signal wird da gar nichts geschaltet - schon gar nicht ab-.
neugierig schrieb: > Das erklär mal genauer. Wieso kann es zu zufälligen Resets kommen und > wie kann der Kondensator das verhindern. ??? Ich verstehe es schlecht... Verstehst du das wirklich nicht oder ist das ein Witz? Wenn doch kein Witz, lese mal bitte über "Antenne", "Kondensator", "Widerstand", "Ohm", "Detektorempfänger".
:
Bearbeitet durch User
Matthias G. schrieb: > An PB4 hab ich eine LED mit vorwiderstand gesteckt Matthias G. schrieb: > #define PIN_LED PE4 da passt was nicht zusammen (PE4, PB4)
Maxim B. schrieb: > Ich verstehe es schlecht... Verstehst du das wirklich nicht oder ist das > ein Witz? Es ist Freitag ...
Angehängte Dateien:
-
oben_.png
24 KB -
unten_.png
26 KB
Qualitäts Inspektor schrieb: > Zeige deinen Aufbau! > > Auch wenn du es nicht glaubst, mit einem mickrigen Abblock- > Kondensator wird dein Controller nicht funktionieren. Dazu > kommt noch dass Vcc und Gnd "vernünftig" geroutet sein müssen. > Das ist bei einem Arduino offensichtlich der Fall. Ob es bei > deinem 256 so ist kann ich nicht beurteilen, jedoch kommen > diese Gedanken bei mir auf nachdem ich die ganze Symptomatik > mitverfolgt habe. Wir haben hier schon viele Layouts gesehen > die diesbezüglich katastrophal waren.... > > Auch kannst du einen Lötfehler am Prozessor haben der das Ding > nicht loslaufen lässt. Immerhin macht das Arduino-Framework > einiges im Hintergrund bevor man mit dem Programmablauf zur > main() gelangt. > > Dass du ihn scheinbar fehlerfrei flashen kannst muss kein > Beweis sein dass der Controller auch sonst einwandfrei > funktioniert. > > YMMV Natürlich will ich es nicht glauben, denn dann wäre ja mein Layout und die viele, damit verbundene Arbeit für die Tonne ;) Ich hänge dir mal mein Layout an. Wenn es was hilft mach ich auch gerne noch bilder von der fertigen Platine. Die ungerouteten Leitungen sind einmal die Reset-Leitung, da hatte ich einen Fehler im Schaltplan... das hab ich schon während der Bestückung erkannt und mit einem Draht korrigiert. Die beiden anderen sind AVCC und AGND, die ich nun nachträglich verbunden habe. Wenn ich das Layout dann neu machen muss, werde ich vielleicht zuerst ein einfaches Breakout-Board für den Mega machen...
:
Bearbeitet durch User
Maxim B. schrieb: > neugierig schrieb: >> Das erklär mal genauer. Wieso kann es zu zufälligen Resets kommen und >> wie kann der Kondensator das verhindern. > > ??? > Ich verstehe es schlecht... Verstehst du das wirklich nicht oder ist das > ein Witz? > > Wenn doch kein Witz, lese mal bitte über "Antenne", "Kondensator", > "Widerstand", "Ohm", "Detektorempfänger". Der Reset Pin ist aktiv low, muß also nach GND gezogen werden um einen Reset auszulösen. Intern hat er einen Pull-Up Widerstand von maximal 60kOhm. Parallel dazu hat der TO noch einen externen 10kOhm Widerstand nach Vcc. Wenn es da zu zufälligen Resets durch Einstrahlungen kommt, ist was anderes faul aber sicher nicht der ausgebaute Kondensator. Deine Lesevorschläge sind alle bekannt aber in diesem Fall nicht relevant. Wenn doch, bin ich auf deine Erläuterung gespannt.
Kann es sein, dass Du das Pinout des ATMega gespiegelt hast? Sieht für mich fast so aus :-)
Dieter F. schrieb: > Kann es sein, dass Du das Pinout des ATMega gespiegelt hast? Sieht für > mich fast so aus :-) Das täuscht... Das ist sozusagen der Blick von oben durch die Platine durch ;)
Matthias G. schrieb: > Das ist sozusagen der Blick von oben durch die Platine > durch ;) Schön - dann sehe ich, das Reset direkt an VCC hängt (die Pads sind verbunden) oder? Falls nicht - kannst Du ggf. eine bessere Auflösung bieten?
Matthias G. schrieb: > > > Zusammenfassung: > - mega2560 lässt sich fehlerfrei flashen > - Clocksignal an SCL ist da > - geflashtes Programm läuft nicht > > Hat jemand eine Idee woran das liegen könnte? Hab ich was übersehen? Hört sich sehr nach (falsch gesetzten) FUSES an. Kurt
Dieter F. schrieb: > Schön - dann sehe ich, das Reset direkt an VCC hängt (die Pads sind > verbunden) oder? Würde ich auch sagen, kann aber auch ein Darstellungs-Fehler durch Verkleinerung sein.
Matthias G. schrieb: > #define PIN_LED PE4 > > void setup() > { > pinMode(PIN_LED, OUTPUT); > } > > void loop() > { > digitalWrite(PIN_LED, HIGH); > delay(500); > digitalWrite(PIN_LED, LOW); > delay(500); > } PE4 ist kein gültiger Arduino Pinbezeichner!!! BZW. macht was anderes, als du meinst. Dein Programm blinkt auf Pin PG5, aber da ist keine Diode dran. Du siehst es also nicht. > #define PIN_LED 4 Macht genau das gleiche! Teste mal:
1 | void setup() |
2 | {
|
3 | DDRE |= _BV(PE4); |
4 | }
|
5 | |
6 | void loop() |
7 | {
|
8 | PINE = _BV(PE4); |
9 | delay(500); |
10 | }
|
Dann blinkt die LED auch auf Pin PE4.
neugierig schrieb: > Der Reset Pin ist aktiv low, muß also nach GND gezogen werden um einen > Reset auszulösen. Intern hat er einen Pull-Up Widerstand von maximal > 60kOhm. Parallel dazu hat der TO noch einen externen 10kOhm Widerstand > nach Vcc. Je nachdem. Mit Kondensator braucht man viel mehr Störungen für falsche Reset, als ohne Kondensator. Kostet das nur 5 Cent, oder auch weniger. Die meisten Kondensatoren sind auch so, zum Verdacht. Z.B. ohne Abblockkondensator kann Schaltung auch arbeiten - meistens. Aber nicht immer. Und wann kommt die Störung weiß man nicht. Vielleicht kommt gar nicht. Vielleicht aber auch jede ein paar Sekunden... Lotterie. Aber ich denke, für so eine Aufgabe, mit LED zu blinken, hier kommen keine Störungen. Wenn fehlende Kondensator sich bemerkbar macht, dann bestimmt in einem viel komplexen Programm. Wenn gleichzeitig mehrere Pin umgeschaltet werden, bei ungünstiger Zusammensetzung und bei höheren kapazitativen Last. Ich selbst mache immer nach dem Prinzip: lieber ein paar billigen Kondensatoren mehr (das schadet nie), als später fieberhaft nach dem Fehler suchen, welche nur unter bestimmten Voraussetzungen einmal in ein paar Stunden kommen (das ist ja bekannte Alptraum eines Programmierers)... Hier bei Reichelt: SMD-Vielschicht-Keramikkondensator 100N, 10%, X7R-G0805 100N 0,01 € Man kann 200 für 2 € kaufen, und für einige Zeit reicht das... Im Moment hat TO aber bestimmt irgendwas mit falschen Quelltext zu tun.
:
Bearbeitet durch User
Ich stimme Dir voll zu Maxim B. > Wie komme ich denn an die Fuses ran? Mit einem Programmieradapter und avrdude (und optional einer GUI dazu, wie z.B. AVR8-Burn-O-Mat). Die Arduino IDE kann Fuses vermutlich nicht anzeigen. > Wieso kann es zu zufälligen Resets kommen und > wie kann der Kondensator das verhindern. Weil der Kondensator Radiowellen kurz schließt, die man eventuell ungewollt über Leitungen (=ungewollte Antennen) empfängt. Man sollte dabei bedeken, dass der Reset Eingang einen sehr schwachen internen Pull-Up hat und dass er recht empfindlich auslöst (nämlich schon wenn die Spannung kleiner als VCC - 0,5V ist). Auf jeden Fall ist es Sinnvoll, den zusätzlichen 10k Ohm Widerstand beizubehalten und einen Kondensator von 100nF dazu zu geben. 22pF ist zu wenig, der bewirkt fast nichts. > Wenn es da zu zufälligen Resets durch Einstrahlungen kommt, ist was > anderes faul aber sicher nicht der ausgebaute Kondensator. Das sehe ich anders. Vor allem Funkmodule in der Nähe sowie buchstäbliche Funken im Raum können durchaus einen sporadischen Reset auslösen, wenn der Pin nur durch einen einfachen 10k Widerstand auf High gezogen wird. Ich bin jedoch ebenfalls sicher, dass dies hier momentan nicht die Problemursache ist.
Stefanus F. schrieb: > Man sollte dabei bedeken, dass der Reset Eingang einen sehr schwachen > internen Pull-Up hat und dass er recht empfindlich auslöst (nämlich > schon wenn die Spannung kleiner als VCC - 0,5V ist). Alles klar. Wenn Vcc = 5V ist, gibt es einen Reset, wenn am Reset-Pin weniger als 4,5V anliegen? Wo steht das?
> Wo steht das? Im Datenblatt http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-2549-8-bit-AVR-Microcontroller-ATmega640-1280-1281-2560-2561_datasheet.pdf Table 31-3: RESET Pin Threshold Voltage Minium 0.2*VCC Maximum 0.9*VCC Die Spannung am Reset Pin muss bei 5V Versorgungsspannung höher als 4,5V sein, um garantiert keinen Reset auszulösen. > VCC - 0,5V War also nur fast richtig. So ist das mit Erinnerungen ab einem gewissen Alter.
Arduino F. schrieb: > PE4 ist kein gültiger Arduino Pinbezeichner!!! > BZW. macht was anderes, als du meinst. > Dein Programm blinkt auf Pin PG5, aber da ist keine Diode dran. Du > siehst es also nicht. >> #define PIN_LED 4 > Macht genau das gleiche! > > Teste mal:
1 | >
|
2 | >
|
3 | > void setup() |
4 | > { |
5 | > DDRE |= _BV(PE4); |
6 | > } |
7 | >
|
8 | > void loop() |
9 | > { |
10 | > PINE = _BV(PE4); |
11 | > delay(500); |
12 | > } |
13 | >
|
> Dann blinkt die LED auch auf Pin PE4.
OK, damit wäre jetzt der erste Fehler gelöst...
Damit hatte ich alle Pins durcheinandergeschmissen. Aber wieso kann ich
PE4 nicht direkt angeben?
Ich habe jetzt halt erstmal die Arduino-Pinbezeichnungen genommen.
Allerdings stürzt er nun ab, sobald ich versuche das Display zu
initialisieren.
Der Code dafür sieht so aus:
#include <SPI.h>
#include <Wire.h>
#include <Adafruit_GFX.h>
#include <Adafruit_SSD1306.h>
#define PIN_LED 2
#define OLED_RESET 4
Adafruit_SSD1306 display(OLED_RESET);
int zahl = 0;
void setup()
{
pinMode(PIN_LED, OUTPUT);
display.begin(SSD1306_SWITCHCAPVCC, 0x3C);
}
void loop()
{
digitalWrite(PIN_LED,HIGH);
delay(200);
digitalWrite(PIN_LED,LOW);
// display.clearDisplay();
// display.setTextSize(1);
// display.setTextColor(WHITE,BLACK);
// display.setCursor(0,0);
// display.print(zahl);
// display.display();
zahl++;
delay(200);
}
Es handelt sich um ein I2C OLED-Display, und der Code funktioniert mit
einem normalen Arduino mega2560 wunderbar. Er bleibt bei display.begin()
hängen (durch viele blinksignale ausgetestet).
Und fragt mich nicht wozu OLED_RESET sein soll. Das Display hat keinen
Reset-Pin.
Das wird dann wohl nun wirklich mit meinen fehlenden Kondensatoren zu
tun haben :(
Matthias G. schrieb: > void setup() > { > pinMode(PIN_LED, OUTPUT); Wenn du mit Arduino-Programm nicht klar kommst, versuch mal mit normaler "C" etwas zu machen. In C gibt es keine versteckten Umstimmungen, alles klar und durchsichtig. So wirst du viel schneller kapieren, was los ist. Du kannst mit C auch Simulator benutzen (das fehlt in Arduino-IDE) und noch mal Programm auf Fehler überprüfen. Ich habe auch ein paar Arduino Mega 2560 in China gekauft, aber nur einmal (für Kontrolle) eins davon aus Arduino-IDE ausprobiert. Ergebnis: fürchterlich. Die Aufgabe, die auf C kompiliert unter 1 kB Hex hat, braucht in Arduino 9 kB Hex! Deshalb benutze ich diese Platten nur mit AVR Studio.
:
Bearbeitet durch User
> Aber wieso kann ich PE4 nicht direkt angeben? Frage das mal die Arduino Erfinder. Ich glaube, es hat ein bisschen mit Kräutern zu tun, die man rauchen kann. > Und fragt mich nicht wozu OLED_RESET sein soll. > Das Display hat keinen Reset-Pin. Manche haben einen und brauchen dann dieses Signal.
Matthias G. schrieb: > Aber wieso kann ich > PE4 nicht direkt angeben? Mannnooo... Weil die Konstanten PB4, PE4 und auch PG4 alle den Wert 4 beinhalten. Der Arduino Mega hat 53 Pins, oder so... Über die Pxx Konstanten kannst du maximal 8 Pins erreichen. Pin 0 bis Pin 7 Wieso wundert dich das? Bist doch ein C Schreiber.... PG4 ist in C, das gleiche PG4 wie in C++, und damit auch unter Arduino. Nichts anderes!
Maxim B. schrieb: > Ergebnis: > fürchterlich. Die Aufgabe, die auf C kompiliert unter 1 kB Hex hat, > braucht in Arduino 9 kB Hex! Was du da wohl für einen Mist gebaut hast? Ich wette, der muss geheim bleiben, damit dir keiner dein schönes Vorurteil zerlegen kann .... Denn irgendwie muss man ja Arduino runter machen.... Also, ist das nur: Unbelegtes Geplärre! Das typische Arduino Bashing.
Stefanus F. schrieb: >> Aber wieso kann ich PE4 nicht direkt angeben? > > Frage das mal die Arduino Erfinder. Ich glaube, es hat ein bisschen mit > Kräutern zu tun, die man rauchen kann. Nee, (oder zumindest nicht nur). Deren Pinnummerierung bezieht sich auf die Steckverbinder. Die sind für alle Boards gleich. Egal, ob AVR oder SAM8. Nucleo-Boards von STM entsprechen auch diesem Standard. Prinzipiell sollte man aber alles, was man mit "normalen" AVR machen kann, auch mit Arduinos machen können - auch mit der Arduino-IDE (bzw. dessen C++-Wrapper).
> Deren Pinnummerierung bezieht sich auf die Steckverbinder. > Die sind für alle Boards gleich. Schön wär's. Schau Dir mal Fotos von den unterschiedlichen Boards an. Mindestens jedes zweite originale und noch mehr "kompatible" passen nicht zum Layout des Uno.
Arduino F. schrieb: > Also, ist das nur: > Unbelegtes Geplärre! > Das typische Arduino Bashing. Weder noch, sondern eine Tatsache! Die Qualität der meisten Arduino-Librarys ist eine Katastrophe, und die "Arduino-Experten" brauchen genau deshalb selbst für simple Aufgaben oft mehr als die 32kB Flash eines AtMega328. Arduino ist nur was für Leute, die zu blöd oder zu faul sind Datenblätter zu lesen und zu verstehen, und am Ende kommt genau sowas wie in diesem Thread dabei heraus, weil man mangels Wissen und/oder Verständnis nicht einmal in der Lage ist simple Fehler eigenständig einzukreisen. Aber einem Arduino-Fanboy zu erzählen, er möge doch mal Grundlagen der Elektronik und Programmierung lernen ist ohnehin vergeblich.... Wer diese Grundlagen drauf hat, wird um diesen ganzen Arduino-Schrott einen ganz, ganz weiten Bogen machen. Die Leute, die das genauso sehen können i.d.R. auch selbstständig programmieren und haben Arduino ausprobiert und verworfen, aber die Arduino-Fanboys kennen i.d.R. eben nur Arduino und haben daher auch keinen Vergleich oder Bewertungs-Maßstab. Und jetzt können die Arduino-Fanboys mich mit ihren Negativ-Bewertungen abstrafen. Ich erwarte nichts Anderes.
Harry L. schrieb: > Arduino ist nur was für Leute, die zu blöd oder zu faul sind > Datenblätter zu lesen und zu verstehen, und am Ende kommt genau sowas > wie in diesem Thread dabei heraus, weil man mangels Wissen und/oder > Verständnis nicht einmal in der Lage ist simple Fehler eigenständig > einzukreisen. Weil man irgendwie anfangen muss? Manche gehen vielleicht etwas blauäugig an die Sache ran, aber das ist ein Lernprozess. Man kommt mit Arduino ziemlich schnell zu einem Erfolgserlebnis. Harry L. schrieb: > Aber einem Arduino-Fanboy zu erzählen, er möge doch mal Grundlagen der > Elektronik und Programmierung lernen ist ohnehin vergeblich.... Darf man nur also ausgebildeter Elektroniker oder womöglich E-Technik-Ing mit Mikrocontrollern "spielen". Harry L. schrieb: > Die Leute, die das genauso sehen können i.d.R. auch selbstständig > programmieren und haben Arduino ausprobiert und verworfen, aber die > Arduino-Fanboys kennen i.d.R. eben nur Arduino und haben daher auch > keinen Vergleich oder Bewertungs-Maßstab. Man darf es professionell nutzen, muss es aber nicht. Wenn man sich die Qualität einiger Datenblätter ansieht, dann dürften nur noch hartgesottene Nerds Mikrocontroller programmieren oder mit Elektrotechnik spielen. Was ist bei einem Anfänger wichtiger? Dass er (sofort) sämtliche Hintergründe kennt, oder durch Erfolge am Ball bleibt? Harry L. schrieb: > Und jetzt können die Arduino-Fanboys mich mit ihren Negativ-Bewertungen > abstrafen. > Ich erwarte nichts Anderes. Dann hättest du dir den Post auch sparen und lieber spazieren gehen können.
Die alte Diskussion ist wenig hilfreich. Arduino hat genauso seine Daseinsberechtigung wie alle anderen, Aber darum gehts hier nicht. Harry L. schrieb: > Arduino ist nur was für Leute, die zu blöd oder zu faul sind > Datenblätter zu lesen und zu verstehen, und am Ende kommt genau sowas > wie in diesem Thread dabei heraus, weil man mangels Wissen und/oder > Verständnis nicht einmal in der Lage ist simple Fehler eigenständig > einzukreisen. Dann erkläre diesen "simplen Fehler" bitte. Ich lerne gerne dazu!
Arduino F. schrieb: > Was du da wohl für einen Mist gebaut hast? > Ich wette, der muss geheim bleiben, damit dir keiner dein schönes > Vorurteil zerlegen kann .... Und auf C war Null Bytes von SRAM besetzt, in Arduino IDE 1 kB! :) Ich vermute, in Arduino IDE gibt es einfach gar kein Optimieren.
Harry L. schrieb: > Wer diese Grundlagen drauf hat, wird um diesen ganzen Arduino-Schrott > einen ganz, ganz weiten Bogen machen. Als billige Versuchsplatte für schnelle Experimente ist Arduino OK.Man muß sie nur auf C programmieren. Leider haben Arduino-Erfinder bei 2560 komischerweise bei allen vier USART Pin für CLK vergessen, auszuführen. Oder war das mit Absicht, um aus USART UART zu machen? Bei allen vier? Das begrenzt natürlich Wert von diesen Platten. Aber man kann sie trotzdem für Proben benutzen. Auf C.
So weit ich weiß verwendet man auch nicht die Buchstaben sondern nur die zahlen für die digitalen Ports also 0 - 53. mit Buchstaben geht es schnell mal schief. Also digital zb pinMode(13, OUTPUT); //LED digitalWrite(13, LOW); Und für analog halt das A pinMode(A0, INPUT); //---- bei der arduino ide gibt es auch die Möglichkeit den code optimieren zulassen damit dieser kleiner wird. Läuft auch ganz gut.
:
Bearbeitet durch User
DAVID -. schrieb: > bei der arduino ide gibt es auch die Möglichkeit den code optimieren > zulassen damit dieser kleiner wird. > Läuft auch ganz gut. Es wäre interessant, zu sehen, wie das bei Arduino übersetzt wird: digitalWrite(13, LOW);
> Es wäre interessant, zu sehen, wie das bei Arduino > übersetzt wird: digitalWrite(13, LOW); Schon ein einfacher Blick in den Quelltext verschafft hier Klarheit.
Stefanus F. schrieb: >> Es wäre interessant, zu sehen, wie das bei Arduino >> übersetzt wird: digitalWrite(13, LOW); > > Schon ein einfacher Blick in den Quelltext verschafft hier Klarheit. GCC macht aus Equivalent PORTB &= ~(1<<PB5); einfach cbi PORTB.5 Ich verstehe einfach schlecht, wozu benutzt Arduino so viel RAM, wenn GCC in gleicher Aufgabe gar ohne RAM klar kommt? Zwar wenn man Optimieren ausschaltet, bekommt man auch von GCC bei PORTB &= ~(1<<PB5); eine Menge von ASM-Befehlen.
:
Bearbeitet durch User
Maxim B. schrieb: > Arduino F. schrieb: >> Was du da wohl für einen Mist gebaut hast? >> Ich wette, der muss geheim bleiben, damit dir keiner dein schönes >> Vorurteil zerlegen kann .... > > Ich vermute, in Arduino IDE gibt es einfach gar kein Optimieren. Arduino nutzt den gleichen Kompiler, wie das Atmel Studio. Standard Optimierungsstufe, unter Arduino, ist -Os Gleicher Quellcode sollte auf beiden Systemen das gleiche Kompilat ergeben. Nahezu. Dazu: Wenn man die die Arduino Komfort Dinge nicht nutzen will, warum auch immer, dann kann man das auch lassen. Und dann wird auch der gleiche Code wie im AS generiert. > Und auf C war Null Bytes von SRAM besetzt, in Arduino IDE 1 kB! :) Und wieder kein Vergleichscode.....
> Ich verstehe einfach schlecht, wozu benutzt Arduino so viel RAM
Ich habe das Gefühl, dass hier einige Leute maßlos übertreiben. Schau
hier:
1 | void setup() { |
2 | pinMode(10,OUTPUT); |
3 | }
|
4 | |
5 | void loop() { |
6 | digitalWrite(10,HIGH); |
7 | digitalWrite(10,LOW); |
8 | }
|
Arduino Nano: 734 Bytes Flash, 9 Bytes RAM Arduino Micro: 4024 Bytes Flash, 149 Bytes RAM (incl. USB Treiber) Maple Mini: 14176 Bytes Flash, 2816 Bytes RAM (incl USB Treiber) ESP8266: 246827 Bytes Flash, 32792 Byte RAM (incl WLAN Treiber) Dabei sollte man nicht vergessen, dass dieser Code bereits den Systemtimer (millis()) enthält. Was man hier auch schön sehen kann ist, dass der Code für die 32bit Mikrocontroller signifikant größer ist, als für AVR. Das ist aber nicht nur beim Arduino Framework so. > Und auf C war Null Bytes von SRAM besetzt, in Arduino IDE 1 kB! Ich komme auf 9 Bytes.
Daß 32-biter mehr brauchen, ist verständlich: wo man auch mit char klar kommt, die brauchen dafür ja auch 4 Bytes! Ich möchte Arduino nicht so grundlos beschimpfen... Mir stört, daß man dort so schwer ASM sehen kann und kein Simulator für Überprüfung. Hat man die Möglichkeit, schnell asm zu sehen, so kann man C-Ausdrücke optimieren.
:
Bearbeitet durch User
Maxim B. schrieb: > Mir stört, daß man dort so schwer ASM sehen kann und kein Simulator für > Überprüfung. Kennst Du das "verhasste" Atmel Studio 7.0? Dort kann man Arduino-Projekte importieren, kompilieren und sich aus allen Richtungen (.lss etc.) anschauen sowie debuggen.
Maxim B. schrieb: > Hat man die Möglichkeit, schnell asm zu sehen, so kann man C-Ausdrücke > optimieren. Wie das geht, habe ich vor kurzem hier publiziert. Siehe: Beitrag "Re: Welche Ressourcen nutzt die Arduino Software?"
Stefanus F. schrieb: > Harry, dein Schrank (im Kopf) hat eindeutig zu wenig Schubladen. Und das sagt jemand, der bei jeder sich bietenden Gelegenheit HAL verteufelt, weil es "angeblich" so schlecht und fehlerhaft ist? Passt irgendwie nicht zusammen, und läßt den Verdacht aufkeimen, daß du ganz andere Probleme hast. Von daher geb ich den Vorwurf gerne mit besten Grüssen zurück.
Stefanus F. schrieb: > Table 31-3: > RESET Pin Threshold Voltage > Minium 0.2*VCC > Maximum 0.9*VCC > > Die Spannung am Reset Pin muss bei 5V Versorgungsspannung höher als 4,5V > sein, um garantiert keinen Reset auszulösen. Figure 32-29. Reset Input Threshold Voltage vs. Vcc im verlinkten Datenblatt besagt, daß bei Vcc = 5V die Spannung am Reset-Pin unter 2,2V fallen muß, um einen Reset auszulösen.
Dieter F. schrieb: > Kennst Du das "verhasste" Atmel Studio 7.0? Ich habe das ausprobiert und wieder gelöscht: zu langsam. ich habe nur Toolchain davon genommen und zu AVR Studio 4.19 kopiert.
Maxim B. schrieb: > Ich habe das ausprobiert und wieder gelöscht: zu langsam. ich habe nur > Toolchain davon genommen und zu AVR Studio 4.19 kopiert. Anfänger - wenn dann schon zu 4.18 zurückkehren :-) "Zu langsam" finde ich immer wieder herrlich - unter Hobbyisten ... 1. Ist es gar nicht "so langsam" 2. Bietet es auch einige Vorteile gegenüber 4.18 / 4.19 ... Aber jeder so, wie er mag. Wenn es Dir nicht gefällt brauchst Du Dich auch nicht darüber zu beschweren, dass Du den Arduino-Code nicht als .lss sehen / debuggen kannst.
> Figure 32-29. Reset Input Threshold Voltage vs. Vcc > im verlinkten Datenblatt besagt, daß bei Vcc = 5V die Spannung am > Reset-Pin unter 2,2V fallen muß, um einen Reset auszulösen. Was sein muss und darf, steht in den Tabellen. Die Diagramme zeigen nur das typische Verhalten, das aber nicht garantiert ist. Um garantiert einen Reset auszulösen, muss die Spannung unter 0.2*VCC sinken. Aber um garantiert keinen Reset auszulösen, muss sie über 0.9*VCC liegen. Dazwischen (also 1,0..4,5V) ist der Bereich, indem er vielleicht einen Reset auslöst. Je nach Stimmungslage, Glück und Materialstreuung. > 1. Ist es gar nicht "so langsam" Das hängt sehr vom Computer ab. Auf einem Pentium M Dual Code mit 4GB RAM läuft das Atmel Studio unerträglich langsam, das AVR Studio aber einwandfrei. Hier ist die Anleitung, wie man sich als Arduino User das Assembler Listing erzeugt: https://ucexperiment.wordpress.com/2012/02/21/arduino-assembly-language-listing-of-compiled-sketch-windows/
Stefanus F. schrieb: > Hier ist die Anleitung, wie man sich als Arduino User das Assembler > Listing erzeugt: Endlos nervend, das jedes mal händisch zu machen... Was gefällt dir an meinem Automatismus nicht?
> Was gefällt dir an meinem Automatismus nicht?
Deine Anleitung gefällt mir auch. Es gibt meisten viele Wege zum Ziel
und über Geschmack soll man nicht streiten.
Dieter F. schrieb: > 2. Bietet es auch einige Vorteile gegenüber 4.18 / 4.19 ... Welche (abgesehen von der zusätzlichen Unterstützung für neuere Devices)? Richtig: ABSOLUT KEINE! Also bleiben nur die Nachteile...
Dieter F. schrieb: > Für Dich stimmt das OK, nehmen wir mal an, ich wäre einfach nur zu blöd, die massiven Vorteile zu erkennen. Da du ja im Gegensatz zu mir sooo schlau bist, kann es dir ja eigentlich auch nicht schwer fallen, sie zu benennen, oder? Also tue das doch einfach mal... Tipp: Irgendwelche Neuerungen der C-Toolchain zählen absolut nicht als Vorteil, denn die kann man auch in die alten Studios implantieren. Für den, der sowas braucht. Also, was bleibt ansonsten noch an wichtigen Vorteilen?
Dieter F. schrieb: > "Zu langsam" finde ich immer wieder herrlich - unter Hobbyisten ... Gerade bei Hobby ist das wichtiger: als Hobbyist solltest du eigene Zeit verschwenden und nicht die Zeit, die dein Arbeitgeber bezahlt! Das ist ja unnützlich verschwendete Zeit, wenn du nach jedem Knopfdruck lange warten muß, solange System irgendwie reagiert. Dieter F. schrieb: > Bietet es auch einige Vorteile gegenüber 4.18 / 4.19 ... Welche? Vielleicht ein paar neue AVR-Typen. Aber ich habe bemerkt: gerade für neue AVR gibt es gar kein Simulator. Deshalb habe ich gedacht: solange mir 8 bit noch reicht, bleibe ich bei der Reihe 644-1284, wenn nicht mehr reicht, dann gehe ich gleich zu STM32. langsame Arbeit ist so starke Nachteil, daß viele Vorteile dabei schon recht wenig Wert haben.
:
Bearbeitet durch User
Stefanus F. schrieb: > Das hängt sehr vom Computer ab. Auf einem Pentium M Dual Code mit 4GB > RAM läuft das Atmel Studio unerträglich langsam, das AVR Studio aber > einwandfrei. Ich habe zwei Laptops: dieser aus dem Jahre 2010. Und noch einen, vor einem Jahr gekauft. Und zur Seite gestellt: der ist viel, viel langsamer als alte bei etwa gleichem Preis! Obwohl alte CPU 2 Kerne hat und der neue schon 4 Kerne! Mit Win10 (von Hersteller geliefert) gar unerträglich langsam. Deshalb habe ich auf den Kubuntu installiert und so lerne etwas Linux-Welt: sowieso mit Windows 10 klar geworden, waß Windows-Ära zu Ende geht. Als Arbeitspferd war ich gezwungen, Laptop aus dem Jahre 2010 weiter zu benutzen. Deshalb ist für mich maßgebend, wie alles genau mit diesem Laptop läuft, was ich benutze. WinXP, 4 GB RAM (XP kann ja nur 3 benutzen), 2 TB Festplatte. Für Programme, die mit XP nicht laufen können, habe ich VirtualBox mit vielen anderen Systemen installiert. Alles aber, was ich dienstlich brauche (Word, Sibelius, SoundForge), läuft mit XP einwandfrei und schnell. Ich bin mit neueren Laptops sehr enttäuscht: um mit neuem Laptop und Win10 nur auf gleiche Leistung zu kommen, welche ich mit einem 500 € - Laptop aus dem 2010 mit WinXP habe, sollte ich mindestens 1500 € ausgeben. Ich kann sie aber viel vernünftiger verschwenden.
:
Bearbeitet durch User
Hi Maxim, deinem Erfahrungsbericht glaube ich. Ich möchte allerdings auch berichten, dass der umgekehrte Fall möglich ist. Ich hatte vor einigen Jahren diesen Pentium M, Dual Core 2,2GHz. Als er nicht mehr zuverlässig funktionierte, kaufte ich bei Conrad für wenig Geld einen neuen gebrauchten, der dort ein Jahr lang lang als Vorführgerät herumgestanden hat. Der neue Laptop hatte nur zwei Kerne mit 1,3GHz und gleich viel RAM. Aber trotzdem lief er insgesamt gefühlt genau so schnell, wie der alte Laptop. Davon war ich angenehm überrascht.
c-hater schrieb: > Also tue das doch einfach mal... Habe ich schon. Aber mir ist es vollkommen egal, ob Du diese auch siehst :-) An Deinen Trittbrettfahrer: Maxim B. schrieb: > Gerade bei Hobby ist das wichtiger: als Hobbyist solltest du eigene Zeit > verschwenden und nicht die Zeit, die dein Arbeitgeber bezahlt! Liest Du eigentlich ab und an, was Du so schreibst? Wahrscheinlich besser nicht :-) Mein Atmel-Studio 7.0.1652 startet in ca. 22 Sekunden auf einem Acer Aspire 7721 aus 2009 (17.11.) mit einer - zugegeben relativ neuen SSD - und Windows 7. Atmel Studio 4.18 braucht bei mir ca. 10 Sekunden (beim ersten Start - später nur noch 4 - 5 Sekunden) - aber das ist mir vollkommen egal.
> Mein Atmel-Studio 7.0.1652 startet in ca. 22 Sekunden Angeber :-) Jedenfalls hast du offensichtlich einen Computer, der für beide Programme prima geeignet ist. Mein gedit startet in 0,7 Sekunden. Das ist mein bevorzugter Editor für AVR Projekte. Ich weiß selbst nicht wie es dazu kam, ich könnte genau so gut auch Atmel Studio, AVR Studio, Eclipse, Netbeans oder QT Creator verwenden. Aber aus irgendeinem Grund bin ich wieder auf die gute alte Kommandozeile gepaart mit einem einfachen Texteditor gekommen. Vielleicht weil ich ein alter Sack bin. Heute ist so ein gedit oder Notepad++ schon der reinste Luxus verglichen mit dem, was mir damals in der Schule vorgesetzt wurde (gwbasic und Borland Pascal).
Beitrag #5420494 wurde von einem Moderator gelöscht.
Dieter F. schrieb: > Atmel Studio 4.18 AVR Studio natürlich - falls sich jemand darüber mockiert :-)
Mit Atmel Studio 7: bei mir startet mehrere Minuten. Dann wenn ich etwas anklicke, "denkt" Computer auch lange, manchmal Minuten. Mit AVR Studio 4.19 kein Vergleich. Ich habe früher 4.18 SP3 benutzt, zuerst mit WinAVR-20100110, dann mit Toolchain. Ein bißchen "Chemie" mit Toolchain lohnt sich, da man moderne GCC-Version (mit __flash und __uint24 ) haben kann (avr-toolchain-installer-3.4.2.1573-win32.win32.x86.exe installiert, danach avr8-gnu-toolchain-installer-3.6.0.1734 Ordner 4.7.2 für 5.4.0 gewechselt). Nur habe ich plötzlich ein Problem festgestellt: wenn im Projekt etwas mehr *.c und *.h Files kommen (ca. ab je 11 ), kommt Fehler beim Compilieren. Ich habe dann 4.19 installiert, und Fehler kommt nicht mehr.
:
Bearbeitet durch User
Maxim B.:
> Mit Atmel Studio 7: bei mir startet mehrere Minuten.
Arbeitet Dein Rechner schon mit Strom?
mfg
>> Mit Atmel Studio 7: bei mir startet mehrere Minuten. > Arbeitet Dein Rechner schon mit Strom? Auf meinem Pentium M lief das Atmel Studio 6 damals auch so langsam.
Also ihr könnt euch ja weiter kloppen, ich klinke mich aus. Mein Problem werde ich anderweitig lösen.
Angehängte Dateien:
-
System.png
15 KB -
VM_AS_6.2.png
7,1 KB
Mein System (Bild) aus 2009 (und immer noch voll ausreichend) ist mit dieser SSD https://www.amazon.de/gp/product/B01IAGSD68 ausgestattet. In einer VM mit XP und schwacher Ressourcen-Einstellung (Bild) habe ich noch eine AS 6.2-Version installiert. Dort benötigt der Start des AS 6.2 natürlich deutlich länger - ca. 2 Min. 30 Sekunden.
Kann ich nicht nachvollziehen. Bei mir: WIN7-64, 4..5 Jahre alter 8 core AMD, SSD (nachgerüstet): gestoppt 21.2 sec. Nutze viel XMEGA und SAM mit ASF, weiss nicht, ob neuere Controller und aktuelle ASF-Versionen von den AVR-Studios 4.xx unterstützt werden. Tipp: PC ein, ATMEL Studio starten, Küche gehen, Kaffe holen, Zurück kommen - Fertsch! mfg
> Kann ich nicht nachvollziehen
Ich sage ja, dass es auf die Ausstattung des Computers ankommt. Das
Atmel Studio ist eines der wenigen Programme wo man die Unterschiede der
CPU's und RAM Menge sehr stark bemerkt.
J Zimmermann schrieb: > Kann ich nicht nachvollziehen. Bei mir: WIN7-64, 4..5 Jahre alter 8 core > AMD, SSD (nachgerüstet): gestoppt 21.2 sec. Ich schon :-) Dieter F. schrieb: > Mein Atmel-Studio 7.0.1652 startet in ca. 22 Sekunden auf einem Acer > Aspire 7721 aus 2009 (17.11.) mit einer - zugegeben relativ neuen SSD - > und Windows 7. Passt doch.
Dieter F. schrieb: > Mein Atmel-Studio 7.0.1652 startet in ca. 22 Sekunden auf einem Acer > Aspire 7721 aus 2009 (17.11.) mit einer - zugegeben relativ neuen SSD - > und Windows 7. Mit einem auch nur halbwegs umfangreichen Projekt? Das glaube ich nicht. Nichtmal näherungsweise. Merke: davon, dass das Studio selber gestartet ist, kannst du noch längst nicht anfangen zu arbeiten. Das geht erst, wenn auch das Projekt geladen ist, an dem du arbeiten willst. Falls dir das noch nicht aufgefallen sein sollte...
Beitrag #5421453 wurde von einem Moderator gelöscht.
c-hater schrieb: > Mit einem auch nur halbwegs umfangreichen Projekt? Das glaube ich nicht. > Nichtmal näherungsweise. https://www.youtube.com/watch?v=kQqH293C_bQ Das Gezackere kommt von Snagit - da kann ich nichts für. Im Projekt sind Grafik-Libs und Elm Chans FFT-Routinen / -Libs enthalten.
c-hater:
> Mit einem auch nur halbwegs umfangreichen Projekt? Das glaube ich nicht.
ich schon, Beispiel: 220k Quellen (*.h,*.c) (bin schreibfaul, void kommt
bei mir nicht vor) lädt in <3s.
mfg
PS: Hassen kann halt sehr unproduktiv sein
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.