main.c aufruf aus dem ordner ".../cores/arduino"

funkheld:
dan werde ich die init .c ändern, wenn die hauptsächliche mit dem timer rumplänkelt.

Ich weiss ja nicht, warum du an der wiring.c rumfummeln willst? Eigene Initialisierungen kannst du ja gut in setup() unterbringen. Wird doch in main.cpp direkt hinter init() aufgerufen.

Außer natürlich, dir gefällt absolut nicht, was in init() ausgeführt wird und du möchtest das wegwerfen. Aber dann musst du dir natürlich der Konsequenzen bewusst sein!

Oder sonst kannst du in deinem Sketch eine Funktion myInit() schreiben, die deine eigenen Initialisierungen enthält. Dann den Aufruf von myInit() in main.cpp vor oder hinter dem Aufruf von init() einfügen und in der Datei wiring.h einen Funktionsprototypen für myInit() einfügen (z.B. hinter den Funktionsprototypen für setup() und loop() ).

Ich weiss ja nicht, warum du an der init.c rumfummeln willst?

die enthält für meine vorhaben unnütze bremsklötze, die ich beseitigen will.
diese wiring.c(2006) ist total überaltet und entspricht nicht mehr den regularium bzw den c-standart von winavr-c.
da werden veraltete namen genutzt zb für die interrups(SIGNAL.... ist veraltet) und andere klamotten.

gruss

funkheld:

Ich weiss ja nicht, warum du an der init.c rumfummeln willst?

die enthält für meine vorhaben unnütze bremsklötze, die ich beseitigen will.
gruss

Nur zur Vermeidung von Verwirrung: Wir sprechen ja wohl beide von wiring.c, nicht von init.c, das so zwischendurch mal auftauchte. Und in wiring.c steckt die Funktion init(), die du aber garnicht anpacken musst, wenn du z.B. SIGNAL durch ISR ersetzen willst.

in der init() steckt auch das alte gelumpe "sbi.." usw , das gibt es seit jahren nicht mehr in der winavr-c und ist verpönt.

alos wer mit dem winavr-c auf dem laufenden sein möchte, sollte die ollen kamellen mal rauswerfen.

gruss

dan werde ich die init .c ändern, wenn die hauptsächliche mit dem timer rumplänkelt.

@funkheld
ich werde aus deinen Aussagen und Kommentaren nicht schlau. :frowning:
Wenn ich dein bisherigen Posts anschauen, bist du nur am Meckern und am Kritisieren der Arduino IDE. Sorry, dass ich das so direkt sage.

Die Arduino-Entwicklungsumgebung ist sicher nicht das Hightec-Produkt unter den Entwicklungsumgebungen. Aber für das Zielpublikum (Bastler, Tüftler, Künstler, Studenten, Lernbegierige..) ist das eine nützliche Umgebung und erfüllt die Anforderungen um die Arduino-Sketche auf einfache Weise zu testen und auf das Board zu laden.

Die Frage wieso du eigentlich zu Arduino gekommen bist (und nicht weiter mit Bascom arbeitest) wurde schon mal in einem anderen Thread gestellt. Für dich ist das, soweit ich das in Erinnerung habe Hobby. Darum sollte die ganze Materie Spass machen.

Ich höre nur immer "steckt auch das alte gelumpe ..."sbi.." ..das gibt es seit jahren nicht mehr ..Timer und PWM-Gedöns".
Wenn du hier die Core-Funktionalität umbauen und verbessern willst, solltest du dich an das Arduino-Core-Team wenden.

Die sehr nützlichen Beiträge von voithian zeigen doch klar, dass man mit der Standard-IDE gut arbeiten kann. Allfällige Anpassungen können über eine clevere Verwendung von Funktionen etc. realisiert werden.

Wie gesagt, wir wollen Spass mit den Arduino-Anwendungen haben, originelle Lösungen realisieren und nicht die vom Arduino-Team bereitsgestellte und kostenloste Entwicklungsumgebung kritisieren, geschweige denn umbauen :wink:

Mir geht es sicherlich ähnlich wie funkheld, indem ich mit den Möglichkeiten, die die Arduino-IDE zur Verfügung stellt, nicht immer zufrieden bin.

Aber hier steht es jedem frei, auf eine andere IDE wie AVR Studio mit AVR-GCC umzusteigen und damit sein C-Programm zu erstellen. Dort hat man (fast) alle Freiheiten und Einflussmöglichkeiten, die man sich wünscht und mit ein bisschen Anpassung kann man auch die Arduino-Funktionen aufrufen (wenn man sie nicht total hasst). Oder notfalls aber eben selber für AVR-GCC und die AVR-GCC-Libraries (um)schreiben.

Und dann das Ganze aus AVR Studio per AVRDUDE (mit Bootloader oder Hardware-Programmer) auf das Arduino-Board laden. Die Arduino-Hardware läuft ja problemlos auch mit Programmen, die mit dem AVR Studio erstellt wurden.

So mach ich's persönlich und lass die Arduino-IDE denen, für die sie gedacht ist.
Und ich glaube, diese Vorgehensweise wäre auch für funkheld und seine Anforderungen das günstigste.

Gruß
Wolfgang

Aber hier steht es jedem frei, auf eine andere IDE wie AVR Studio mit AVR-GCC umzusteigen...
...
So mach ich's persönlich und lass die Arduino-IDE denen, für die sie gedacht ist.

@voithian
So soll es doch sein. Jeder nutzt das Werkzeug welche seine Bedürfnisse abdeckt.

Wobei Anfänger sicher auch nichts gegen eine bessere IDE hätten :wink: Ich nutze die auch schon lange nicht mehr. Eigentlich nutze ich nur noch Teile der Libraries als Beispiele. Aber jeder wie er es will.

Udo

Wobei Anfänger sicher auch nichts gegen eine bessere IDE hätten

Da wünscht sich wohl jeder. :slight_smile:
Aber bei den ersten Schritte mit Arduino wird sich ein Anfänger kaum noch mit einem weiteren Tool rumschlagen wollen. Die Einfachheit der IDE hat hier auch seine Vorteile.

Wieso noch ein weiteres Tool? Ich habe nicht gesagt noch eine IDE sondern eine bessere IDE.

Udo

Man muss den Sinn von Open Source nur vertsehen um zu wissen:

Änderungen -insbesondere die Sinnvollen - werden Einzug halten :slight_smile: Aber das vermutlich nicht im deutschen Forum sondern eher bei den Leuten die sich um CORE Angelegenheiten kümmern,

Wieso noch ein weiteres Tool?

Weil es noch keine bessere IDE gibt. So muss man auf andere Tools ausweichen. :wink:

Wenn es eine verbesserte IDE geben würde, braucht man natürlich keine weiteren Tools.

...bist du nur am Meckern und am Kritisieren der Arduino IDE.

hmmm..., was hat die ide damit zu tun. gar nichts!
es ist das sogenannte hilfreiche toolspektakel....
weil durch die zucompilierten core-sourcen teilweise das reale vom atmeg328p durcheinander gebracht wird.

warum kann man nicht die delays... so schreiben:

void delay(unsigned long ms)
{
	_delay_ms(ms);
}

void delayMicroseconds(unsigned int us)
{
	_delay_us(us);
	
}

statt diesen langen code in der wiring.c :

unsigned long millis()
{
	unsigned long m;
	uint8_t oldSREG = SREG;
	
	// disable interrupts while we read timer0_millis or we might get an
	// inconsistent value (e.g. in the middle of the timer0_millis++)
	cli();
	m = timer0_millis;
	SREG = oldSREG;
	
	return m;
}

unsigned long micros() {
	unsigned long m, t;
	uint8_t oldSREG = SREG;
	
	cli();	
	t = TCNT0;
  
#ifdef TIFR0
	if ((TIFR0 & _BV(TOV0)) && (t == 0))
		t = 256;
#else
	if ((TIFR & _BV(TOV0)) && (t == 0))
		t = 256;
#endif

	m = timer0_overflow_count;
	SREG = oldSREG;
	
	return ((m << 8) + t) * (64 / clockCyclesPerMicrosecond());
}

void delay(unsigned long ms)
{
	unsigned long start = millis();
	
	while (millis() - start <= ms)
		;
}

/* Delay for the given number of microseconds.  Assumes a 8 or 16 MHz clock. 
 * Disables interrupts, which will disrupt the millis() function if used
 * too frequently. */
void delayMicroseconds(unsigned int us)
{
	uint8_t oldSREG;

	// calling avrlib's delay_us() function with low values (e.g. 1 or
	// 2 microseconds) gives delays longer than desired.
	//delay_us(us);

#if F_CPU >= 16000000L
	// for the 16 MHz clock on most Arduino boards

	// for a one-microsecond delay, simply return.  the overhead
	// of the function call yields a delay of approximately 1 1/8 us.
	if (--us == 0)
		return;

	// the following loop takes a quarter of a microsecond (4 cycles)
	// per iteration, so execute it four times for each microsecond of
	// delay requested.
	us <<= 2;

	// account for the time taken in the preceeding commands.
	us -= 2;
#else
	// for the 8 MHz internal clock on the ATmega168

	// for a one- or two-microsecond delay, simply return.  the overhead of
	// the function calls takes more than two microseconds.  can't just
	// subtract two, since us is unsigned; we'd overflow.
	if (--us == 0)
		return;
	if (--us == 0)
		return;

	// the following loop takes half of a microsecond (4 cycles)
	// per iteration, so execute it twice for each microsecond of
	// delay requested.
	us <<= 1;

	// partially compensate for the time taken by the preceeding commands.
	// we can't subtract any more than this or we'd overflow w/ small delays.
	us--;
#endif

	// disable interrupts, otherwise the timer 0 overflow interrupt that
	// tracks milliseconds will make us delay longer than we want.
	oldSREG = SREG;
	cli();

	// busy wait
	__asm__ __volatile__ (
		"1: sbiw %0,1" "\n\t" // 2 cycles
		"brne 1b" : "=w" (us) : "0" (us) // 2 cycles
	);

	// reenable interrupts.
	SREG = oldSREG;
}

ich habe nichts gegen alle tool-c-sourcen.
etliche sind wunderbar für den 382p geschrieben.

gruss

Die Libraries sind in der Tat nicht immer so prickelnd. Wenn Du Verbesserungen hast, dann bring sie doch einfach ein. Gute Vorschläge werden normalerweise aufgenommen. Bloß weil Dein Code kürzer aussieht muß das Kompilat aber nicht notwendig besser sein. Hast Du schon mal per Disassembler nachgeschaut ob Dein Vorschlag wirklich besser ist? Bzw. warum die Lösung aus der Library nicht so ersetzt werden kann? In der Regel liegt der Teufel im Detail.

Hast Du schon mal per Disassembler nachgeschaut ob Dein Vorschlag wirklich besser ist?

es kommt darauf an wie man den level einstellt in winavr-c "0,1,S,2,3" alle binärdateien sind dann unterschiedlich.
auch wird bei diesen levels die länge der delay beeinflusst zb.

gruss

Also hast Du NICHT nachgeschaut sondern gibst eine allgemeine Erkenntnis zum Besten. Wie Webmeister werde ich aus Deinen Sprüchen auch nicht schlau.

Wenn Du soviel kannst wie Du tönst, warum schaust Du dann nicht einfach in den Sourcen nach statt solche Fragen wie Deine Eingangsfrage zu stellen? Die Arduino Libs sind ja nicht wirklich groß. Sowas zieht sich jeder C Experte locker in ein paar Stunden durch.

Und ja: die Libs sind nicht super toll. Die wirkliche Arbeit steckt in der AVR-LIBC. Der eigentliche Nutzen steckt in der bequemen Verschalung. Wenn die Dir nicht gefällt, dann benutze sie doch einfach nicht. Ich nehme sie auch nur wenn sie mir nützt. Wenn nicht dann nicht.

Udo

ich weiss nicht, was du immer für ein kartoffelsalat redest.
dein geplärre geht mir auf den geist...

gruss

Hallo funkheld

Mir gefällt nicht eine solche Sprache lesen zu müssen.

Bitte benutze eine gemäßigte Ausdrucksweise.

Die Antworten Die Du bekommen hast sind sicher provokativ aber nicht beleidigend.
Wenn Du in einem solchen Ton schreibst, wer soll Dir noch antworten oder mit Dir diskutieren wollen?

Viele Grüße Uwe

@Uwe: tja, das ist leider der Nachteil eines Forums. Wenn das eine NG wäre, dann hätte es jetzt plonk gemacht und gut ist. Hier geht das anscheinend nur für PMs. Oder kennt jemand noch weitere Einstellungen?

Udo