Groups > de.sci.electronics > #241454 > unrolled thread

Arduino IDE

Started by	Eric Bruecklmeier <usenet@nerdcraft.de>
First post	2018-02-27 14:03 +0100
Last post	2018-03-01 15:12 +0100
Articles	20 on this page of 78 — 23 participants

Back to article view | Back to de.sci.electronics

  Arduino IDE Eric Bruecklmeier <usenet@nerdcraft.de> - 2018-02-27 14:03 +0100
    Re: Arduino IDE Gregor Szaktilla <spam0.sz@ktilla.de> - 2018-02-27 14:06 +0100
      Re: Arduino IDE Eric Bruecklmeier <usenet@nerdcraft.de> - 2018-02-27 14:10 +0100
        Re: Arduino IDE Gregor Szaktilla <spam0.sz@ktilla.de> - 2018-02-27 14:29 +0100
          Re: Arduino IDE Eric Bruecklmeier <usenet@nerdcraft.de> - 2018-02-27 14:37 +0100
            Re: Arduino IDE Gregor Szaktilla <spam0.sz@ktilla.de> - 2018-02-27 14:50 +0100
      Re: Arduino IDE Hermann Riemann <nospam.ng@hermann-riemann.de> - 2018-02-27 16:20 +0100
        Re: Arduino IDE Gregor Szaktilla <spam0.sz@ktilla.de> - 2018-02-27 16:34 +0100
        Re: Arduino IDE Josef Moellers <josef.moellers@invalid.invalid> - 2018-02-27 16:43 +0100
          Re: Arduino IDE Gregor Szaktilla <spam0.sz@ktilla.de> - 2018-02-27 16:48 +0100
            Nachtrag (war: Re: Arduino IDE) Gregor Szaktilla <spam0.sz@ktilla.de> - 2018-02-27 17:12 +0100
            Re: Arduino IDE Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2018-02-28 12:02 +0100
              Re: Arduino IDE Gregor Szaktilla <spam0.sz@ktilla.de> - 2018-02-28 14:27 +0100
        Re: Arduino IDE Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2018-02-28 12:31 +0100
          Re: Arduino IDE Reinhardt Behm <rbehm@hushmail.com> - 2018-02-28 21:14 +0800
            Re: Arduino IDE Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2018-02-28 16:22 +0100
    Re: Arduino IDE Edzard Egberts <news@edzeg.net> - 2018-02-27 14:13 +0100
      Re: Arduino IDE Eric Bruecklmeier <usenet@nerdcraft.de> - 2018-02-27 14:35 +0100
    Re: Arduino IDE Josef Moellers <josef.moellers@invalid.invalid> - 2018-02-27 16:06 +0100
    Re: Arduino IDE "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2018-02-27 15:40 +0000
      Re: Arduino IDE Josef Moellers <josef.moellers@invalid.invalid> - 2018-02-27 16:48 +0100
        Re: Arduino IDE Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2018-02-28 12:08 +0100
    Re: Arduino IDE Joerg <news@analogconsultants.com> - 2018-02-27 07:44 -0800
      Re: Arduino IDE Eric Bruecklmeier <usenet@nerdcraft.de> - 2018-02-27 17:16 +0100
        Re: Arduino IDE Joerg <news@analogconsultants.com> - 2018-02-27 09:47 -0800
          Re: Arduino IDE Gregor Szaktilla <spam0.sz@ktilla.de> - 2018-02-27 19:29 +0100
            Re: Arduino IDE Joerg <news@analogconsultants.com> - 2018-02-27 10:46 -0800
              Re: Arduino IDE Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2018-02-28 12:27 +0100
                Re: Arduino IDE Joerg <news@analogconsultants.com> - 2018-02-28 07:22 -0800
                  Re: Arduino IDE Bernd Laengerich <Bernd.Laengerich@web.de> - 2018-02-28 17:03 +0100
                    Re: Arduino IDE Joerg <news@analogconsultants.com> - 2018-02-28 09:14 -0800
                    Re: Arduino IDE Gerald Oppen <Gerald.Oppen@web.de> - 2018-02-28 20:02 +0100
                      Re: Arduino IDE Bernd Laengerich <bernd.laengerich@web.de> - 2018-02-28 22:36 +0100
                        Re: Arduino IDE Gerald Oppen <Gerald.Oppen@web.de> - 2018-03-01 19:18 +0100
                          Re: Arduino IDE Joerg <news@analogconsultants.com> - 2018-03-01 11:47 -0800
                            Re: Arduino IDE Volker Bartheld <news2017@bartheld.net> - 2018-03-02 10:13 +0100
                              Re: Arduino IDE Bernd Laengerich <Bernd.Laengerich@web.de> - 2018-03-02 11:04 +0100
                                Re: Arduino IDE Volker Bartheld <news2017@bartheld.net> - 2018-03-02 12:04 +0100
                                  Re: Arduino IDE Joerg Niggemeyer <joerg.niggemeyer@nucon.de> - 2018-03-02 12:28 +0100
                                    Re: Arduino IDE "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2018-03-02 11:42 +0000
                                    Re: Arduino IDE Joerg <news@analogconsultants.com> - 2018-03-02 11:22 -0800
                            Re: Arduino IDE Joerg Niggemeyer <joerg.niggemeyer@nucon.de> - 2018-03-02 11:03 +0100
                          Re: Arduino IDE Bernd Laengerich <bernd.laengerich@web.de> - 2018-03-01 21:23 +0100
                            Re: Arduino IDE Joerg Niggemeyer <joerg.niggemeyer@nucon.de> - 2018-03-02 10:43 +0100
                              Re: Arduino IDE Bernd Laengerich <Bernd.Laengerich@web.de> - 2018-03-02 11:02 +0100
                      Re: Arduino IDE Dieter Wiedmann <dieter.wiedmann@t-online.de> - 2018-03-01 09:09 +0100
            Re: Arduino IDE Hanno Foest <hurga-news2@tigress.com> - 2018-02-27 19:48 +0100
              Re: Arduino IDE Gregor Szaktilla <spam0.sz@ktilla.de> - 2018-02-27 20:07 +0100
              Re: Arduino IDE Bernd Laengerich <Bernd.Laengerich@web.de> - 2018-02-28 09:49 +0100
                Re: Arduino IDE Eric Bruecklmeier <usenet@nerdcraft.de> - 2018-02-28 09:56 +0100
                  Re: Arduino IDE Bernd Laengerich <Bernd.Laengerich@web.de> - 2018-02-28 10:30 +0100
                  Re: Arduino IDE Johannes Bauer <dfnsonfsduifb@gmx.de> - 2018-03-04 11:00 +0100
                    Re: Arduino IDE Eric Bruecklmeier <usenet@nerdcraft.de> - 2018-03-04 11:33 +0100
                      Re: Arduino IDE Johannes Bauer <dfnsonfsduifb@gmx.de> - 2018-03-04 18:33 +0100
                        Re: Arduino IDE Eric Bruecklmeier <usenet@nerdcraft.de> - 2018-03-05 08:51 +0100
                          Re: Arduino IDE Johannes Bauer <dfnsonfsduifb@gmx.de> - 2018-03-05 22:48 +0100
                    Re: Arduino IDE Marte Schwarz <marte.schwarz@gmx.de> - 2018-03-04 15:01 +0100
                      Re: Arduino IDE Joerg <news@analogconsultants.com> - 2018-03-05 08:02 -0800
                        Re: Arduino IDE "Ralph A. Schmid, dk5ras" <ralph@schmid.xxx> - 2018-03-06 08:43 +0100
                          Re: Arduino IDE Eric Bruecklmeier <usenet@nerdcraft.de> - 2018-03-06 08:48 +0100
      Re: Arduino IDE "Ralph A. Schmid, dk5ras" <ralph@schmid.xxx> - 2018-03-02 09:45 +0100
        Re: Arduino IDE Joerg <news@analogconsultants.com> - 2018-03-02 11:28 -0800
          Re: Arduino IDE "Ralph A. Schmid, dk5ras" <ralph@schmid.xxx> - 2018-03-05 15:49 +0100
            Re: Arduino IDE Joerg <news@analogconsultants.com> - 2018-03-05 07:43 -0800
              Re: Arduino IDE "Ralph A. Schmid, dk5ras" <ralph@schmid.xxx> - 2018-03-06 08:47 +0100
                Re: Arduino IDE Joerg <news@analogconsultants.com> - 2018-03-06 07:48 -0800
    Re: Arduino IDE Wolfgang Bußmann <w.bussmann@gmx.de> - 2018-02-27 17:47 +0100
      Re: Arduino IDE Eric Bruecklmeier <usenet@nerdcraft.de> - 2018-02-27 18:26 +0100
        Re: Arduino IDE Eric Bruecklmeier <usenet@nerdcraft.de> - 2018-02-27 20:12 +0100
          Re: Arduino IDE Marte Schwarz <marte.schwarz@gmx.de> - 2018-02-28 14:13 +0100
            Re: Arduino IDE Eric Bruecklmeier <usenet@nerdcraft.de> - 2018-02-28 17:43 +0100
        Re: Arduino IDE Wolfgang <wsc.allmail@web.de> - 2018-02-28 08:50 +0100
          Re: Arduino IDE Eric Bruecklmeier <usenet@nerdcraft.de> - 2018-02-28 09:04 +0100
            Re: Arduino IDE Wolfgang <wsc.allmail@web.de> - 2018-02-28 11:51 +0100
              Re: Arduino IDE Eric Bruecklmeier <usenet@nerdcraft.de> - 2018-02-28 12:15 +0100
    Re: Arduino IDE Patrick Schaefer <pa.schaefer@web.de> - 2018-02-27 21:15 +0100
      Re: Arduino IDE "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2018-02-28 08:25 +0000
        Re: Arduino IDE Peter Thoms <dl6lat@darc.de> - 2018-03-01 15:12 +0100

Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →

#241478

From	Josef Moellers <josef.moellers@invalid.invalid>
Date	2018-02-27 16:48 +0100
Message-ID	<fflcv1F1kqkU1@mid.individual.net>
In reply to	#241474

On 27.02.2018 16:40, Peter Heitzer wrote:
> Eric Bruecklmeier <usenet@nerdcraft.de> wrote:
>> Über kurz oder lang werde ich mich mit Arduino beschäftigen müssen :-(, 
>> daher habe ich mir mal die offizielle IDE angesehen - das geht leider 
>> überhaupt nicht. Was wird denn hier so verwendet? Falls überhaupt...
> 
> avr-gcc, make und avr-dude. Ein Arduino ist im Wesenlichen auch nur ein
> normaler ATMega, ergänzt um einen USB-Controller zur Programmierung.
> Wenn du über ISP den Controller programmierst, brauchst du das Drumherum nicht.
> 
> Bei der Arduino IDE sind zwar sehr viele Bibliotheken für verschiedenste
> Anwendungsgebiete enthalten, aber ich habe den Eindruck, daß die 
> Codequalität eher durchschnittlich ist. 

Dazu kommt, daß ein Modul halt nix voraussetzen darf bzw umgekehrt so
wenig wie möglich an Hardware-Modulen benutzen darf, z.B. benutzt der
Code um einen DHT22 auszulesen keinen Timer, obwohl das vielleicht
einfacher wäre.

Klar, man muß das Rad nicht zigmal neu erfinden, aber wenn man weiß, was
man tun möchte, geht's besser ohne.

Josef

[toc] | [prev] | [next] | [standalone]

#241524

From	Hans-Peter Diettrich <DrDiettrich1@aol.com>
Date	2018-02-28 12:08 +0100
Message-ID	<ffnildFgglmU2@mid.individual.net>
In reply to	#241478

Am 27.02.2018 um 16:48 schrieb Josef Moellers:

> Dazu kommt, daß ein Modul halt nix voraussetzen darf bzw umgekehrt so
> wenig wie möglich an Hardware-Modulen benutzen darf, z.B. benutzt der
> Code um einen DHT22 auszulesen keinen Timer, obwohl das vielleicht
> einfacher wäre.

Die Ressourcen-Verwaltung stört mich auch. Aber wie könnte man so etwas 
überhaupt zum Laufen bringen?

Bei ARM Prozessoren soll das ja noch viel schlimmer sein?

DoDi

[toc] | [prev] | [next] | [standalone]

#241476

From	Joerg <news@analogconsultants.com>
Date	2018-02-27 07:44 -0800
Message-ID	<fflcm0F1ikfU1@mid.individual.net>
In reply to	#241454

On 2018-02-27 05:03, Eric Bruecklmeier wrote:
> Über kurz oder lang werde ich mich mit Arduino beschäftigen müssen :-(,
> daher habe ich mir mal die offizielle IDE angesehen - das geht leider
> überhaupt nicht.

Ich weiss nicht, was bei Dir nicht geht, aber erstmal mein Beileid zum 
Thema "muessen". Einer meiner Kunden benutzt das und es ist ein Graus. 
Man will irgendwo direkt ein Register im ATMega beschreiben und 
irgendwie setzt die IDE das wieder anders. Dann die tollen 
Reset-Vorschlaege, um den seriellen Adapter dranzufroempeln. IMO alles 
nicht empfehlenswert. Fuer Bastler mag es ja gehen.

>   ... Was wird denn hier so verwendet? Falls überhaupt...
>

Bei den Kunden, die unbedingt ATMega oder AVR wollen, benutzen sie 
professionelle Suites. Manche Studio, der SW-Ingenieur, mit dem ich gern 
zusammenarbeite (schreibe selbst keine) mag IAR. Das kostet dann, ist 
aber dafuer anstaendig und man bekommt bei IAR guten Support.

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

[toc] | [prev] | [next] | [standalone]

#241482

From	Eric Bruecklmeier <usenet@nerdcraft.de>
Date	2018-02-27 17:16 +0100
Message-ID	<ffleigFub6vU3@mid.individual.net>
In reply to	#241476

Am 27.02.2018 um 16:44 schrieb Joerg:
> On 2018-02-27 05:03, Eric Bruecklmeier wrote:
>> Über kurz oder lang werde ich mich mit Arduino beschäftigen müssen :-(,
>> daher habe ich mir mal die offizielle IDE angesehen - das geht leider
>> überhaupt nicht.
> 
> 
> Ich weiss nicht, was bei Dir nicht geht,

Das Teil ist der absolute Müll. Kann gar nichts und läßt sich nicht mal 
mehr sauber deinstallieren.

Ich hab jetzt mal Platformio versucht, scheint etwas besser zu sein, 
aber es läuft z.B. auch keines der Beispiele für das WEMOS ESP Board 
(obwohl es das können sollte). Irgendwie bekommt er die Library 
Abhängigkeiten nicht aufgelöst.

Ja, auf dem Arduino Nano eine LED blinken lassen bekomme ich hin.

Alles in Allem ziemlich frustrierender Schrott...

[toc] | [prev] | [next] | [standalone]

#241486

From	Joerg <news@analogconsultants.com>
Date	2018-02-27 09:47 -0800
Message-ID	<ffljt4F37l7U1@mid.individual.net>
In reply to	#241482

On 2018-02-27 08:16, Eric Bruecklmeier wrote:
> Am 27.02.2018 um 16:44 schrieb Joerg:
>> On 2018-02-27 05:03, Eric Bruecklmeier wrote:
>>> Über kurz oder lang werde ich mich mit Arduino beschäftigen müssen :-(,
>>> daher habe ich mir mal die offizielle IDE angesehen - das geht leider
>>> überhaupt nicht.
>>
>>
>> Ich weiss nicht, was bei Dir nicht geht,
>
> Das Teil ist der absolute Müll. Kann gar nichts und läßt sich nicht mal
> mehr sauber deinstallieren.
>
> Ich hab jetzt mal Platformio versucht, scheint etwas besser zu sein,
> aber es läuft z.B. auch keines der Beispiele für das WEMOS ESP Board
> (obwohl es das können sollte). Irgendwie bekommt er die Library
> Abhängigkeiten nicht aufgelöst.
>

Oder Du aenderst was im Code und die IDE trampelt einfach drueber.

> Ja, auf dem Arduino Nano eine LED blinken lassen bekomme ich hin.
>

Fuer viel mehr wuerde ich das auch nicht benutzen.

> Alles in Allem ziemlich frustrierender Schrott...
>

Sehe ich auch so. Besonders frustrierend ist, wenn man eine unorthodoxe 
Idee im uC umsetzen moechte und dann vom Programmierer gesagt bekommt, 
dass das mit der Arduino IDE leider so nicht geht.

Die Arduino Idee an sich ist gut, da sie wenigstens einige Leute der 
naechsten Generation fuer Embedded begeistert. Wenn es bei Dir jedoch 
nicht um Schulungen in Richtung Maker Scene geht, wuerde ich was anderes 
waehlen.

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

[toc] | [prev] | [next] | [standalone]

#241488

From	Gregor Szaktilla <spam0.sz@ktilla.de>
Date	2018-02-27 19:29 +0100
Message-ID	<p7481o$lvu$1@news.albasani.net>
In reply to	#241486

Am 27.02.2018 um 18:47 schrieb Joerg:
> ... unorthodoxe
> Idee im uC umsetzen moechte ...

Kannst Du sagen, was für eine Idee das ist? Ich kann mir gerade beim
besten Willen nicht vorstellen, was das sein könnte.

Gruß

Gregor


-- 
X-ggl-piss-off: yes

[toc] | [prev] | [next] | [standalone]

#241489

From	Joerg <news@analogconsultants.com>
Date	2018-02-27 10:46 -0800
Message-ID	<fflnchF412mU1@mid.individual.net>
In reply to	#241488

On 2018-02-27 10:29, Gregor Szaktilla wrote:
> Am 27.02.2018 um 18:47 schrieb Joerg:
>> ... unorthodoxe
>> Idee im uC umsetzen moechte ...
>
> Kannst Du sagen, was für eine Idee das ist? Ich kann mir gerade beim
> besten Willen nicht vorstellen, was das sein könnte.
>

Es sind Echtzeitvorgaenge. Wenn man z.B. ein Timer-Register nach genau 
xx Taktzyklen umstellen muss, aber nicht nach xx-2 oder xx+1. 
Comparator-gesteuerte Umstellung interner Register, wo die Anzahl der 
Taktzyklen ebenfalls genau festliegen muss. Externe Loop auf eine 
Kapazitaetsdiode am Taktquarz zwecks Phasenmodulation, die vom uC selbst 
PWM-gesteuert wird, da externer DAC zu teuer. Und aehnliches.

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

[toc] | [prev] | [next] | [standalone]

#241525

From	Hans-Peter Diettrich <DrDiettrich1@aol.com>
Date	2018-02-28 12:27 +0100
Message-ID	<ffnildFgglmU3@mid.individual.net>
In reply to	#241489

Am 27.02.2018 um 19:46 schrieb Joerg:
> On 2018-02-27 10:29, Gregor Szaktilla wrote:
>> Am 27.02.2018 um 18:47 schrieb Joerg:
>>> ... unorthodoxe
>>> Idee im uC umsetzen moechte ...
>>
>> Kannst Du sagen, was für eine Idee das ist? Ich kann mir gerade beim
>> besten Willen nicht vorstellen, was das sein könnte.
>>
> 
> Es sind Echtzeitvorgaenge. Wenn man z.B. ein Timer-Register nach genau 
> xx Taktzyklen umstellen muss, aber nicht nach xx-2 oder xx+1.

Dafür brauchst Du eine IDE, die Assembler gut unterstützt, Takte zählen 
kann, und weiteres Gedöns. Und wenn sich dann herausstellt, daß der 
gewählte Controller die Anforderungen nicht schafft, muß man mit einem 
anderen Controller ganz von vorne anfangen - falls das überhaupt 
zulässig ist.

> Comparator-gesteuerte Umstellung interner Register, wo die Anzahl der 
> Taktzyklen ebenfalls genau festliegen muss. Externe Loop auf eine 
> Kapazitaetsdiode am Taktquarz zwecks Phasenmodulation, die vom uC selbst 
> PWM-gesteuert wird, da externer DAC zu teuer. Und aehnliches.

Nimm einen ausreichend schnellen Controller, bei dem man nicht den 
letzten Takt rausquetschen muß. Alles andere ist IMO unprofessionell, 
und das wollen wir doch nicht :-]

[toc] | [prev] | [next] | [standalone]

#241545

From	Joerg <news@analogconsultants.com>
Date	2018-02-28 07:22 -0800
Message-ID	<ffnvqaFjdg9U1@mid.individual.net>
In reply to	#241525

On 2018-02-28 03:27, Hans-Peter Diettrich wrote:
> Am 27.02.2018 um 19:46 schrieb Joerg:
>> On 2018-02-27 10:29, Gregor Szaktilla wrote:
>>> Am 27.02.2018 um 18:47 schrieb Joerg:
>>>> ... unorthodoxe
>>>> Idee im uC umsetzen moechte ...
>>>
>>> Kannst Du sagen, was für eine Idee das ist? Ich kann mir gerade beim
>>> besten Willen nicht vorstellen, was das sein könnte.
>>>
>>
>> Es sind Echtzeitvorgaenge. Wenn man z.B. ein Timer-Register nach genau
>> xx Taktzyklen umstellen muss, aber nicht nach xx-2 oder xx+1.
>
> Dafür brauchst Du eine IDE, die Assembler gut unterstützt, Takte zählen
> kann, und weiteres Gedöns. Und wenn sich dann herausstellt, daß der
> gewählte Controller die Anforderungen nicht schafft, muß man mit einem
> anderen Controller ganz von vorne anfangen - falls das überhaupt
> zulässig ist.
>

Der uC hat die Anforderungen bisher immer geschafft. Die IDE war das 
Problem.


>> Comparator-gesteuerte Umstellung interner Register, wo die Anzahl der
>> Taktzyklen ebenfalls genau festliegen muss. Externe Loop auf eine
>> Kapazitaetsdiode am Taktquarz zwecks Phasenmodulation, die vom uC
>> selbst PWM-gesteuert wird, da externer DAC zu teuer. Und aehnliches.
>
> Nimm einen ausreichend schnellen Controller, bei dem man nicht den
> letzten Takt rausquetschen muß. Alles andere ist IMO unprofessionell,
> und das wollen wir doch nicht :-]


Das geht oft nicht, weil jeder Cent umgedreht werden muss. Nicht bei 
jeder Produktentwicklung kann man einfach einen uC waehlen, der 
garantiert locker ausreicht. In Extremfaellen muss man mit einem 
chinesischen 4-Bitter hinkommen, wo es mit normalen Compiler Suites 
allerdings eh vorbei ist.

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

[toc] | [prev] | [next] | [standalone]

#241548

From	Bernd Laengerich <Bernd.Laengerich@web.de>
Date	2018-02-28 17:03 +0100
Message-ID	<ffo26oFjuohU1@mid.individual.net>
In reply to	#241545

Am 28.02.2018 um 16:22 schrieb Joerg:

> Der uC hat die Anforderungen bisher immer geschafft. Die IDE war das Problem.

Glaubst Du eigentlich selber an den Unsinn den Du hier verbreitest?

Eine IDE integriert nur die für die Entwicklung ohnehin nötigen Werkzeuge und 
erleichtert ggf. die Entwicklung, da die vorkommenden Arbeitsschritte wie 
Edieren, assemblieren, kompilieren, linken und flashen in einer Oberfläche 
zusammengefasst werden. Manche mögen das, andere nicht. Wenn das Programm aber 
nicht das tut, was man erwartet, ist in den wenigsten Fällen die IDE daran 
schuld. Eigenständig Sourcecode verändernde IDEs sind eher unüblich und wer es 
mit Atmel-Studio (eine IDE) nicht hinbekommt "ein Register im ATMega zu 
beschreiben", wird es auch ohne IDE nicht.

Bernd

[toc] | [prev] | [next] | [standalone]

#241554

From	Joerg <news@analogconsultants.com>
Date	2018-02-28 09:14 -0800
Message-ID	<ffo6b5Fksi6U1@mid.individual.net>
In reply to	#241548

On 2018-02-28 08:03, Bernd Laengerich wrote:
> Am 28.02.2018 um 16:22 schrieb Joerg:
>
>> Der uC hat die Anforderungen bisher immer geschafft. Die IDE war das
>> Problem.
>
> Glaubst Du eigentlich selber an den Unsinn den Du hier verbreitest?
>

Nicht glauben, wissen.


> Eine IDE integriert nur die für die Entwicklung ohnehin nötigen
> Werkzeuge und erleichtert ggf. die Entwicklung, da die vorkommenden
> Arbeitsschritte wie Edieren, assemblieren, kompilieren, linken und
> flashen in einer Oberfläche zusammengefasst werden. Manche mögen das,
> andere nicht. Wenn das Programm aber nicht das tut, was man erwartet,
> ist in den wenigsten Fällen die IDE daran schuld. Eigenständig
> Sourcecode verändernde IDEs sind eher unüblich und wer es mit
> Atmel-Studio (eine IDE) nicht hinbekommt "ein Register im ATMega zu
> beschreiben", wird es auch ohne IDE nicht.
>

Es war faktisch so, dass _dieselbe_ Routine unter Arduino IDE nicht lief 
und unter einer gescheiten Suite lief.

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

[toc] | [prev] | [next] | [standalone]

#241555

From	Gerald Oppen <Gerald.Oppen@web.de>
Date	2018-02-28 20:02 +0100
Message-ID	<ffocmqFmcv3U1@mid.individual.net>
In reply to	#241548

Am 28.02.2018 um 17:03 schrieb Bernd Laengerich:
> Am 28.02.2018 um 16:22 schrieb Joerg:
> 
>> Der uC hat die Anforderungen bisher immer geschafft. Die IDE war das 
>> Problem.
> 
> Glaubst Du eigentlich selber an den Unsinn den Du hier verbreitest?
> 
> Eine IDE integriert nur die für die Entwicklung ohnehin nötigen 
> Werkzeuge und erleichtert ggf. die Entwicklung, da die vorkommenden 
> Arbeitsschritte wie Edieren, assemblieren, kompilieren, linken und 
> flashen in einer Oberfläche zusammengefasst werden. Manche mögen das, 
> andere nicht. Wenn das Programm aber nicht das tut, was man erwartet, 
> ist in den wenigsten Fällen die IDE daran schuld. Eigenständig 
> Sourcecode verändernde IDEs sind eher unüblich und wer es mit 
> Atmel-Studio (eine IDE) nicht hinbekommt "ein Register im ATMega zu 
> beschreiben", wird es auch ohne IDE nicht.

Jörg weiss wovon er schreibt.
Deine Aussage passt vielleicht zu den Durchschnittsanwendungen, wenn es 
dann aber mal anspruchsvoller wird trennt sich die Spreu vom Weizen.
Fängt schon bei der Codeoptimierung an.

Gerald

[toc] | [prev] | [next] | [standalone]

#241556

From	Bernd Laengerich <bernd.laengerich@web.de>
Date	2018-02-28 22:36 +0100
Message-ID	<ffoln1Foe0cU1@mid.individual.net>
In reply to	#241555

Am 28.02.2018 um 20:02 schrieb Gerald Oppen:

> Jörg weiss wovon er schreibt.

Da bin ich mir nicht so sicher, er entwickelt soweit ich weiß keine
Software. Ich gebe zu daß ich derzeit relativ wenig mit Atmel und gcc/as
mache. Insgesamt gibt es bei der Embedded-Programmierung deutlich mehr
Fallgruben als es sich der "normale" Applikationsentwickler gemeinhin
vorstellt.

> Deine Aussage passt vielleicht zu den Durchschnittsanwendungen, wenn es
> dann aber mal anspruchsvoller wird trennt sich die Spreu vom Weizen.

Es gibt mehrere IDEs für Atmel, viele davon benutzen die GNU-basierte
toolchain mit make, avr-gcc und -as, ld, u.A. auch Atmel Studio. Andere
Compiler wie IAR oder Rowley Crossworks (Keil macht AFAIK kein AVR, aber
z.B. 8051 und ARM) können und werden natürlich anders arbeiten (und
haben ggf. weniger, mehr oder andere Fehler, je nach Version), aber das
ist selbstverständlich und nicht IDE-spezifisch, üblicherweise sind
sowohl die Optionen für den build anders als auch eventuelle
Inline-Code-Optionen wie #pragma. Ich mag aber nicht glauben, daß z.B.
gcc und as, mit den selben Schaltern aufgerufen, aus dem gleichen Source
unterschiedlichen Code produzieren und dabei magisch "erkennen", ob sie
von einer IDE, von Hand oder aus einem makefile von jenkins aufgerufen
werden.

Die Arduino-IDE erlaubt keine direkte Steuerung der buildparameter (sie
sind in den Konfigurationsdateien hardware/platform.txt,
hardware/arduino/avr/platform.txt und möglicherweise weiteren
versteckt), daher ist sie für anspruchsvollere Anwendung mit
projektspezifischen Einstellungen weniger geeignet, das schrieb ich ja
an Eric. Wer, aus welchen Gründen auch immer, die Arduino-IDE statt
beispielsweise Atmel Studio nutzen möchte, wird dann sinnvollerweise auf
ein makefile ausweichen und dabei Arduino Builder oder Arduino-Makefile
zusätzlich nutzen.

> Fängt schon bei der Codeoptimierung an.

"Die IDE" macht keine Codeoptimierung, das macht, wenn man es denn
erlaubt, der Compiler/Assembler der Toolchain, gesteuert durch
Projektoptionen die beispielsweise im makefile vergraben werden. Hier
ging es um das direkte beschreiben eines ATMega-Registers, das wäre
üblicherweise Assembler (in C hat man eingeschränkt Einfluss auf die
Registerwahl per global oder local register variable definition),
entweder inline oder als Assembler-Datei. Der Optimierungseinfluß dazu
kann nur im Zusammenhang betrachtet werden, nicht an Hand eines
einzelnen Befehles. Natürlich gibt es in verschiedenen Versionen auch
verschiedene Bugs, aber auch hier sehe ich nicht "die IDE" als
verantwortlich dafür an. Wer allerdings Takte zählt und zeitkritische
Sachen macht, wird um zumindest teilweise Assembler nicht herumkommen
und dort dann vermutlich auch Optimierungen abschalten. avr-as hat AFAIK
keine Optimierungen, avr-gcc schon. Und Inline-Assembler ist nicht vor
Optimierungen geschützt, dazu gibt es z.B. Beispiele wie dieses:

<https://www.microchip.com/webdoc/AVRLibcReferenceManual/optimization_1optim_code_reorder.html>

Bernd

[toc] | [prev] | [next] | [standalone]

#241564

From	Gerald Oppen <Gerald.Oppen@web.de>
Date	2018-03-01 19:18 +0100
Message-ID	<ffqufaF9e4nU1@mid.individual.net>
In reply to	#241556

Am 28.02.2018 um 22:36 schrieb Bernd Laengerich:

>> Fängt schon bei der Codeoptimierung an.
> 
> "Die IDE" macht keine Codeoptimierung, das macht, wenn man es denn 
> erlaubt, der Compiler/Assembler der Toolchain, gesteuert durch 
> Projektoptionen die beispielsweise im makefile vergraben werden. Hier 

Da sollten wir uns erstmal über die Begriffe einigen, für mich gehört 
auch der Compiler zur IDE mit dazu, auch wenn er eventuell getauscht 
werden kann.


Gerald

[toc] | [prev] | [next] | [standalone]

#241570

From	Joerg <news@analogconsultants.com>
Date	2018-03-01 11:47 -0800
Message-ID	<ffr3n4Fak5iU1@mid.individual.net>
In reply to	#241564

On 2018-03-01 10:18, Gerald Oppen wrote:
> Am 28.02.2018 um 22:36 schrieb Bernd Laengerich:
>
>>> Fängt schon bei der Codeoptimierung an.
>>
>> "Die IDE" macht keine Codeoptimierung, das macht, wenn man es denn
>> erlaubt, der Compiler/Assembler der Toolchain, gesteuert durch
>> Projektoptionen die beispielsweise im makefile vergraben werden. Hier
>
> Da sollten wir uns erstmal über die Begriffe einigen, für mich gehört
> auch der Compiler zur IDE mit dazu, auch wenn er eventuell getauscht
> werden kann.
>

So ist es. Der Benutzer sieht nur die komplette Software Suite und 
erwartet, dass die funktioniert, so wie sie ist. Und da ist es eben so, 
dass wir z.B. mit der Arduino Suite staendig Problem hatten, mit IAR 
nicht. Natuerlich kann man alles umbasteln, doch man baut ja z.B. auch 
beim Auto als Normalnutzer nicht "mal eben" einen anderen Motor ein, 
weil der urspruengliche nicht taugt.

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

[toc] | [prev] | [next] | [standalone]

#241582

From	Volker Bartheld <news2017@bartheld.net>
Date	2018-03-02 10:13 +0100
Message-ID	<19owa2rzq0fo4.dlg@news.bartheld.net>
In reply to	#241570

On Thu, 01 Mar 2018 11:47:56 -0800, Joerg wrote:
> On 2018-03-01 10:18, Gerald Oppen wrote:
>> Am 28.02.2018 um 22:36 schrieb Bernd Laengerich:
>>>> Fängt schon bei der Codeoptimierung an.
>>> "Die IDE" macht keine Codeoptimierung, das macht, wenn man es denn
>>> erlaubt, der Compiler/Assembler
>> für mich gehört
>> auch der Compiler zur IDE mit dazu, auch wenn er eventuell getauscht
>> werden kann.
> So ist es. Der Benutzer sieht nur die komplette Software Suite und 
> erwartet, dass die funktioniert, so wie sie ist. Und da ist es eben so, 
> dass wir z.B. mit der Arduino Suite staendig Problem hatten

Fehler in Compilern sind keineswegs ein Luxus, den sich nur irgendwelche
Lösungen für Microcontroller oder Open-Source-IDEs leisten. Wer aufmerksam
die Changelogs liest, wird erkennen, daß es z. B. im Microsoft Visual
Studio vor Problemen nur so wimmelt. Bugs in Microprozessoren selbst sind
ebenfalls nicht erst seit Spectre/Meltdown oder FDIV im Pentium ein Thema,
schon der gute alte Z80 von Zilog war dahingehend nicht zuende entwickelt:
https://en.wikipedia.org/wiki/Zilog_Z80#Bugs

Es funktioniert - bei näherer Betrachtung - also genau gar nichts "so wie
es ist". Man kann seinen Code gewissen Unit- und Integrationstests
unterziehen und bei hinreichender Testabdeckung hoffen, daß beim Endnutzer
nichts Schlimmes passiert. Ja, es existieren Ansätze, das komplette
Verhalten einer Softwareimplementierung so zu definieren, daß der
(automatisch generierte) Programmcode zu 100% dieses Verhalten
widerspiegelt, aber dort gibt es andere Pferdefüße.

Ich behaupte also, daß sich die unterschiedlichen IDEs für den
Arduino/ATmega genau gar nichts geben. Das ist wie Schraubendreher, Hammer,
Flachzange und Gabelschlüssel. Wenn Du sie falsch einsetzt, gehen sie
kaputt. Und es gibt qualitativ hochwertigere Werkzeuge - die man mit etwas
Mühe auch ruinieren kann.

Ciao,
Volker

-- 
@:  W E B 2 0 1 7 at B A R T H E L D dot N E T
3W: www.bartheld.net

[toc] | [prev] | [next] | [standalone]

#241589

From	Bernd Laengerich <Bernd.Laengerich@web.de>
Date	2018-03-02 11:04 +0100
Message-ID	<ffsltlFkvilU1@mid.individual.net>
In reply to	#241582

Am 02.03.2018 um 10:13 schrieb Volker Bartheld:

> Es funktioniert - bei näherer Betrachtung - also genau gar nichts "so wie
> es ist". 
[...]

> Flachzange und Gabelschlüssel. Wenn Du sie falsch einsetzt, gehen sie
> kaputt. Und es gibt qualitativ hochwertigere Werkzeuge - die man mit etwas
> Mühe auch ruinieren kann.

Sehe ich auch so. Und wenn es um trickreiche Bitschubsereien, allzu exaktes 
Timing etc. geht: Da hat man mit einer Hochsprache ohnehin quasi verloren, die 
Freiheiten die ein Compiler hat sind derart immens, daß man bei Embedded 
schnell an Grenzen stößt. Die Reihenfolge in dem Hochsprachenstatements 
tatsächlich irgendwie vom Prozessor ausgeführt werden ist weitgehend wahlfrei, 
es gibt Sachen die nirgendwo garantiert werden (also weder im Sprachstandard 
noch vom Compilerhersteller definiert), die Definition von memory barriers 
etc. helfen da manchmal ein wenig, aber auch nicht vollständig. Und Sachen wie 
konkrete Registerbelegung etc. werden üblicherweise auch nicht definiert, da 
kann sich das Update des Compilers auch schon mal überraschend auswirken, wenn 
der Entwickler Annahmen trifft, die so nicht garantiert werden.

Ein guter Entwickler wird bei "seiner" Entwicklungsumgebung, "seinen" 
Bibliotheken und "seiner" Toolchain bleiben, weil er weiß, das der größte 
Aufwand nicht das Erstellen des Sourcecodes ist, sondern das Gesamtsystem zu 
kennen, seine Grenzen und Möglichkeiten. Die Umstellung von einem Compiler auf 
einen anderen ist erfahrungsgemäß immer schmerzhaft, keiner wird sich das ohne 
Not antun.

Bernd

[toc] | [prev] | [next] | [standalone]

#241594

From	Volker Bartheld <news2017@bartheld.net>
Date	2018-03-02 12:04 +0100
Message-ID	<1gw7j64lp7o0l$.dlg@news.bartheld.net>
In reply to	#241589

On Fri, 2 Mar 2018 11:04:37 +0100, Bernd Laengerich wrote:
> Am 02.03.2018 um 10:13 schrieb Volker Bartheld:
>> Es funktioniert - bei näherer Betrachtung - also genau gar nichts "so wie
>> es ist". 
> [...]
>> Flachzange und Gabelschlüssel. Wenn Du sie falsch einsetzt, gehen sie
>> kaputt. Und es gibt qualitativ hochwertigere Werkzeuge - die man mit etwas
>> Mühe auch ruinieren kann.

> Sehe ich auch so. Und wenn es um trickreiche Bitschubsereien, allzu exaktes 
> Timing etc. geht: Da hat man mit einer Hochsprache ohnehin quasi verloren

... und steigt in Assembler ein. BTDT, seinerzeit beim Z80 und natürlich
auch beim ATmega, wenn es z. B. um schnellere A/D-Konvertierungen, komplexe
Interruptsteuerungen, usw. geht.

Volker

-- 
@:  W E B 2 0 1 7 at B A R T H E L D dot N E T
3W: www.bartheld.net

[toc] | [prev] | [next] | [standalone]

#241595

From	Joerg Niggemeyer <joerg.niggemeyer@nucon.de>
Date	2018-03-02 12:28 +0100
Message-ID	<3a4672d256.assel@nuconverter.de>
In reply to	#241594

In message <1gw7j64lp7o0l$.dlg@news.bartheld.net>
          Volker Bartheld <news2017@bartheld.net> wrote:

> On Fri, 2 Mar 2018 11:04:37 +0100, Bernd Laengerich wrote:
>> Am 02.03.2018 um 10:13 schrieb Volker Bartheld:

>> Sehe ich auch so. Und wenn es um trickreiche Bitschubsereien, allzu exaktes
>> Timing etc. geht: Da hat man mit einer Hochsprache ohnehin quasi verloren

> ... und steigt in Assembler ein. BTDT, seinerzeit beim Z80 und natürlich
> auch beim ATmega, wenn es z. B. um schnellere A/D-Konvertierungen, komplexe
> Interruptsteuerungen, usw. geht.

Bits setzen bzw. MCU Hardware konfigurieren, IR Management  geht auch 
aus C heraus. Assemblercode  kann auch in C eingebunden werden.

Manchmal ist es ratsam, den erzeugten Code des Compilers anzusehen, 
falls man meint, er sei fehlerhaft. Dann kannst Du ebenso gut 
erkennen, ob eine Optmierung besser abgeschaltet wird. Meistens sitzt 
die Fehlerquelle jedoch vor der Tastatur.

-- 
mit freundlichen Gruessen/ best regards Joerg Niggemeyer Dipl.Physiker
WEB: http://www.nucon.de    https://www.led-temperature-protection.com
Steinbecker Muehlenweg 95, 21244 Buchholz idN,  Germany
UST-IDNR.: DE 231373311, phone: +49 4181 290913, fax: +49 4181 350504

[toc] | [prev] | [next] | [standalone]

#241596

From	"Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de>
Date	2018-03-02 11:42 +0000
Message-ID	<ffsrkkFlp4fU2@mid.individual.net>
In reply to	#241595

Joerg Niggemeyer <joerg.niggemeyer@nucon.de> wrote:
>In message <1gw7j64lp7o0l$.dlg@news.bartheld.net>
>          Volker Bartheld <news2017@bartheld.net> wrote:

>> On Fri, 2 Mar 2018 11:04:37 +0100, Bernd Laengerich wrote:
>>> Am 02.03.2018 um 10:13 schrieb Volker Bartheld:

>>> Sehe ich auch so. Und wenn es um trickreiche Bitschubsereien, allzu exaktes
>>> Timing etc. geht: Da hat man mit einer Hochsprache ohnehin quasi verloren

>> ... und steigt in Assembler ein. BTDT, seinerzeit beim Z80 und natürlich
>> auch beim ATmega, wenn es z. B. um schnellere A/D-Konvertierungen, komplexe
>> Interruptsteuerungen, usw. geht.

>Bits setzen bzw. MCU Hardware konfigurieren, IR Management  geht auch 
>aus C heraus. Assemblercode  kann auch in C eingebunden werden.

>Manchmal ist es ratsam, den erzeugten Code des Compilers anzusehen, 
>falls man meint, er sei fehlerhaft. Dann kannst Du ebenso gut 
>erkennen, ob eine Optmierung besser abgeschaltet wird. Meistens sitzt 
>die Fehlerquelle jedoch vor der Tastatur.

Ein vergessenes "volatile" kann zu lustigen Effekten führen. Bei einem
Scheduler für den 6507 hatte ich vergessen, nach dem Reset den Dezimalmodus
explizit zu löschen. Die Adressberechnungen funktionierten dennoch meistens :-)

-- 
Dipl.-Inform(FH) Peter Heitzer, peter.heitzer@rz.uni-regensburg.de

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →

csiph-web

Arduino IDE

Contents

#241478

#241524

#241476

#241482

#241486

#241488

#241489

#241525

#241545

#241548

#241554

#241555

#241556

#241564

#241570

#241582

#241589

#241594

#241595

#241596