Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

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

Quelloffenes Microcontroller-Oekosystem?

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

Contents

  Quelloffenes Microcontroller-Oekosystem? <usenet@teply.info> - 2016-12-13 23:35 +0100
    Re: Quelloffenes Microcontroller-Oekosystem? "MaWin" <me@private.net> - 2016-12-13 23:58 +0100
      Re: Quelloffenes Microcontroller-Oekosystem? <floh@aluminium.mobile.teply.info> - 2016-12-14 06:38 +0100
        Re: Quelloffenes Microcontroller-Oekosystem? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2016-12-14 14:47 +0100
          Re: Quelloffenes Microcontroller-Oekosystem? "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2016-12-14 14:15 +0000
            Re: Quelloffenes Microcontroller-Oekosystem? Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de> - 2016-12-14 15:30 +0000
              Re: Quelloffenes Microcontroller-Oekosystem? "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2016-12-14 16:10 +0000
                Re: Quelloffenes Microcontroller-Oekosystem? Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de> - 2016-12-14 16:26 +0000
    Re: Quelloffenes Microcontroller-Oekosystem? Gerald Oppen <Gerald.Oppen@web.de> - 2016-12-14 00:05 +0100
      Re: Quelloffenes Microcontroller-Oekosystem? <usenet@teply.info> - 2016-12-14 06:48 +0100
        Re: Quelloffenes Microcontroller-Oekosystem? Volker Bartheld <news2016@bartheld.net> - 2016-12-14 13:27 +0100
          Re: Quelloffenes Microcontroller-Oekosystem? Edzard Egberts <news@edzeg.net> - 2016-12-14 13:53 +0100
            Re: Quelloffenes Microcontroller-Oekosystem? Florian Teply <usenet@teply.info> - 2016-12-14 21:14 +0100
              Re: Quelloffenes Microcontroller-Oekosystem? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2016-12-15 09:37 +0100
    Re: Quelloffenes Microcontroller-Oekosystem? Axel Schwenke <axel.schwenke@gmx.de> - 2016-12-14 01:11 +0100
      Re: Quelloffenes Microcontroller-Oekosystem? Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de> - 2016-12-14 10:11 +0000
      Re: Quelloffenes Microcontroller-Oekosystem? Rafael Deliano <rafael_deliano@arcor.de> - 2016-12-14 18:16 +0100
        Re: Quelloffenes Microcontroller-Oekosystem? Michael Schwingen <news-1457978346@discworld.dascon.de> - 2016-12-14 22:31 +0000
    Re: Quelloffenes Microcontroller-Oekosystem? Edzard Egberts <news@edzeg.net> - 2016-12-14 13:19 +0100
      Re: Quelloffenes Microcontroller-Oekosystem? Matthias Weingart <mwnews@pentax.boerde.de> - 2016-12-16 08:07 +0000
        Re: Quelloffenes Microcontroller-Oekosystem? Edzard Egberts <news@edzeg.net> - 2016-12-16 09:29 +0100
          Re: Quelloffenes Microcontroller-Oekosystem? Matthias Weingart <mwnews@pentax.boerde.de> - 2016-12-16 09:27 +0000
            Re: Quelloffenes Microcontroller-Oekosystem? Matthias Weingart <mwnews@pentax.boerde.de> - 2016-12-16 09:34 +0000
              Re: Quelloffenes Microcontroller-Oekosystem? Edzard Egberts <news@edzeg.net> - 2016-12-16 11:06 +0100
            Re: Quelloffenes Microcontroller-Oekosystem? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2016-12-18 15:38 +0100
        Re: Quelloffenes Microcontroller-Oekosystem? Lutz Schulze <lschulze@netzwerkseite.de> - 2016-12-16 12:03 +0100
          Re: Quelloffenes Microcontroller-Oekosystem? Michael Bäuerle <michael.baeuerle@stz-e.de> - 2016-12-16 12:25 +0100
            Re: Quelloffenes Microcontroller-Oekosystem? Olaf Kaluza <olaf@criseis.ruhr.de> - 2016-12-16 13:54 +0100
              Re: Quelloffenes Microcontroller-Oekosystem? Michael Bäuerle <michael.baeuerle@stz-e.de> - 2016-12-16 15:27 +0100
                Re: Quelloffenes Microcontroller-Oekosystem? Olaf Kaluza <olaf@criseis.ruhr.de> - 2016-12-16 19:05 +0100
                  Re: Quelloffenes Microcontroller-Oekosystem? Michael Bäuerle <michael.baeuerle@stz-e.de> - 2016-12-19 10:12 +0100
                    Re: Quelloffenes Microcontroller-Oekosystem? Olaf Kaluza <olaf@criseis.ruhr.de> - 2016-12-19 12:18 +0100
                      Re: Quelloffenes Microcontroller-Oekosystem? Chris Jones <lugnut808@spam.yahoo.com> - 2016-12-19 23:27 +1100
                        Re: Quelloffenes Microcontroller-Oekosystem? Michael Bäuerle <michael.baeuerle@stz-e.de> - 2016-12-19 14:31 +0100
                      Re: Quelloffenes Microcontroller-Oekosystem? "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2016-12-19 12:38 +0000
                      Re: Quelloffenes Microcontroller-Oekosystem? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2016-12-23 21:47 +0100
                    Re: Quelloffenes Microcontroller-Oekosystem? Michael Schwingen <news-1457978346@discworld.dascon.de> - 2016-12-19 19:34 +0000
                    Re: Quelloffenes Microcontroller-Oekosystem? Florian Teply <usenet@teply.info> - 2016-12-19 20:14 +0100
              Re: Quelloffenes Microcontroller-Oekosystem? Marte Schwarz <marte.schwarz@gmx.de> - 2016-12-16 17:22 +0100
                Re: Quelloffenes Microcontroller-Oekosystem? Werner Holtfreter <Holtfreter@gmx.de> - 2016-12-16 18:15 +0100
              Re: Quelloffenes Microcontroller-Oekosystem? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2016-12-18 15:58 +0100
        Re: Quelloffenes Microcontroller-Oekosystem? Volker Bartheld <news2016@bartheld.net> - 2016-12-16 13:16 +0100
          Re: Quelloffenes Microcontroller-Oekosystem? Olaf Kaluza <olaf@criseis.ruhr.de> - 2016-12-16 14:14 +0100
            Re: Quelloffenes Microcontroller-Oekosystem? Volker Bartheld <news2016@bartheld.net> - 2016-12-16 15:31 +0100
              Re: Quelloffenes Microcontroller-Oekosystem? Olaf Kaluza <olaf@criseis.ruhr.de> - 2016-12-16 19:22 +0100
                Re: Quelloffenes Microcontroller-Oekosystem? Volker Bartheld <news2016@bartheld.net> - 2016-12-16 19:56 +0100
                  Re: Quelloffenes Microcontroller-Oekosystem? <floh@aluminium.mobile.teply.info> - 2016-12-17 15:17 +0100
                    Re: Quelloffenes Microcontroller-Oekosystem? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2016-12-18 16:11 +0100
                      Re: Quelloffenes Microcontroller-Oekosystem? Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de> - 2016-12-18 15:25 +0000
                      Re: Quelloffenes Microcontroller-Oekosystem? Michael Schwingen <news-1457978346@discworld.dascon.de> - 2016-12-18 16:10 +0000
                        Re: Quelloffenes Microcontroller-Oekosystem? Olaf Kaluza <olaf@criseis.ruhr.de> - 2016-12-18 18:56 +0100
                          Re: Quelloffenes Microcontroller-Oekosystem? Michael Schwingen <news-1457978346@discworld.dascon.de> - 2016-12-18 20:13 +0000
                            Re: Quelloffenes Microcontroller-Oekosystem? Olaf Kaluza <olaf@criseis.ruhr.de> - 2016-12-18 22:06 +0100
                              Re: Quelloffenes Microcontroller-Oekosystem? Michael Schwingen <news-1457978346@discworld.dascon.de> - 2016-12-19 09:23 +0000
                                Re: Quelloffenes Microcontroller-Oekosystem? Olaf Kaluza <olaf@criseis.ruhr.de> - 2016-12-19 12:22 +0100
                          Re: Quelloffenes Microcontroller-Oekosystem? Matthias Weingart <mwnews@pentax.boerde.de> - 2016-12-19 10:32 +0000
                      Re: Quelloffenes Microcontroller-Oekosystem? Florian Teply <usenet@teply.info> - 2016-12-18 21:23 +0100
                        Re: Quelloffenes Microcontroller-Oekosystem? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2016-12-19 21:08 +0100
                Re: Quelloffenes Microcontroller-Oekosystem? "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2016-12-19 08:50 +0000
                  Re: Quelloffenes Microcontroller-Oekosystem? Axel Berger <Axel_Berger@B.Maus.De> - 2016-12-19 09:56 +0100
                    Re: Quelloffenes Microcontroller-Oekosystem? "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2016-12-19 11:14 +0000
        Re: Quelloffenes Microcontroller-Oekosystem? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2016-12-18 14:47 +0100
          Re: Quelloffenes Microcontroller-Oekosystem? Volker Bartheld <news2016@bartheld.net> - 2016-12-18 19:40 +0100
            Re: Quelloffenes Microcontroller-Oekosystem? Christian Zietz <newsgroup.1001@chz.xyz> - 2016-12-18 20:00 +0100
              Re: Quelloffenes Microcontroller-Oekosystem? Volker Bartheld <news2016@bartheld.net> - 2016-12-19 12:00 +0100
            Re: Quelloffenes Microcontroller-Oekosystem? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2016-12-19 12:06 +0100
          Re: Quelloffenes Microcontroller-Oekosystem? "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2016-12-19 08:59 +0000
            Re: Quelloffenes Microcontroller-Oekosystem? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2016-12-19 12:15 +0100
          Re: Quelloffenes Microcontroller-Oekosystem? Matthias Weingart <mwnews@pentax.boerde.de> - 2016-12-19 09:04 +0000
            Re: Quelloffenes Microcontroller-Oekosystem? Michael Schwingen <news-1457978346@discworld.dascon.de> - 2016-12-19 09:36 +0000
        Re: Quelloffenes Microcontroller-Oekosystem? Marcel Mueller <news.5.maazl@spamgourmet.org> - 2016-12-19 23:25 +0100
          Re: Quelloffenes Microcontroller-Oekosystem? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2016-12-26 22:51 +0100
    Re: Quelloffenes Microcontroller-Oekosystem? Marc Santhoff <m.santhoff@t-online.de> - 2016-12-14 18:38 +0100
      Re: Quelloffenes Microcontroller-Oekosystem? Dieter Wiedmann <dieter.wiedmann@t-online.de> - 2016-12-14 19:03 +0100
        Re: Quelloffenes Microcontroller-Oekosystem? Rafael Deliano <rafael_deliano@arcor.de> - 2016-12-14 19:52 +0100
          Re: Quelloffenes Microcontroller-Oekosystem? Dieter Wiedmann <dieter.wiedmann@t-online.de> - 2016-12-14 20:08 +0100
      Re: Quelloffenes Microcontroller-Oekosystem? Olaf Kaluza <olaf@criseis.ruhr.de> - 2016-12-14 20:06 +0100
        Re: Quelloffenes Microcontroller-Oekosystem? Marc Santhoff <m.santhoff@t-online.de> - 2016-12-14 23:03 +0100
          Re: Quelloffenes Microcontroller-Oekosystem? Olaf Kaluza <olaf@criseis.ruhr.de> - 2016-12-15 07:34 +0100
            Re: Quelloffenes Microcontroller-Oekosystem? <floh@aluminium.mobile.teply.info> - 2016-12-15 23:09 +0100
              Re: Quelloffenes Microcontroller-Oekosystem? Olaf Kaluza <olaf@criseis.ruhr.de> - 2016-12-16 09:07 +0100
        Re: Quelloffenes Microcontroller-Oekosystem? "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2016-12-15 09:25 +0000
      Re: Quelloffenes Microcontroller-Oekosystem? Florian Teply <usenet@teply.info> - 2016-12-14 23:12 +0100
        Re: Quelloffenes Microcontroller-Oekosystem? Lutz Schulze <lschulze@netzwerkseite.de> - 2016-12-15 07:12 +0100
          Re: Quelloffenes Microcontroller-Oekosystem? "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2016-12-15 09:40 +0000
            Re: Quelloffenes Microcontroller-Oekosystem? Edzard Egberts <news@edzeg.net> - 2016-12-15 11:13 +0100
              Re: Quelloffenes Microcontroller-Oekosystem? "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2016-12-15 12:21 +0000
        Re: Quelloffenes Microcontroller-Oekosystem? Marc Santhoff <m.santhoff@t-online.de> - 2016-12-15 14:54 +0100
          Re: Quelloffenes Microcontroller-Oekosystem? Florian Teply <usenet@teply.info> - 2016-12-15 22:08 +0100
        Re: Quelloffenes Microcontroller-Oekosystem? Michael Schwingen <news-1457978346@discworld.dascon.de> - 2016-12-15 23:07 +0000
          Re: Quelloffenes Microcontroller-Oekosystem? Florian Teply <usenet@teply.info> - 2016-12-16 15:01 +0100
            Re: Quelloffenes Microcontroller-Oekosystem? Michael Schwingen <news-1457978346@discworld.dascon.de> - 2016-12-16 20:27 +0000
    Re: Quelloffenes Microcontroller-Oekosystem? Matthias Weingart <mwnews@pentax.boerde.de> - 2016-12-16 07:47 +0000
      Re: Quelloffenes Microcontroller-Oekosystem? Florian Teply <usenet@teply.info> - 2016-12-16 15:49 +0100

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

#218585

floh@aluminium.mobile.teply.info wrote:

 >Hmm, SuperH. Hab ich vor langer Zeit auch schon mit geliebäugelt, weil
 >es den SH2 auch mit DSP-Funktionen gibt. Auch den anderen Krempel von 

Richtig. SH2A.

 >Äh, ich hab ja garkein Japanisch-Wörterbuch. Mal sehen, ob im Quelltext
 >was lesbareres zu finden ist...

Quelltext ist in sich schon lesbar. Wer braucht da mehr. :)

 >> 
 >> Dann gibt es natuerlich noch die grossen Renesas wie meinen
 >> Lieblingsprozessor (SH7262). Der hat kein Flash sondern bootet aus
 >> einem externen SPI-Flash. Da bekommt man seine Daten leicht rein.
 >> Darauf hab ich ja meinen MP3-Player unter Linux entwickelt. Das Dingen
 >> hat schon ordentlich Leistung unter der Haube. (1MB-Ram, DualportRAM,
 >> SuperScalar, Cache, alles an Schnittstellen was es gibt, acht
 >> Registersaetze fuer schnelle IRQs, usw)  
 >> 
 >Mal sehen, ob ich das jetzt richtig mitgemeisselt hab: Den Flash
 >beschreibst Du ebenfalls mit dem J-Link, und der Controller führt
 >vermutlich einfach den ersten Code aus den er findet, richtig?

Der Controller bootet aus dem externen SPI-Flash. Das beschreibst du
mit allem das dir einfaellt. In meinem Falle ein
USB-SPI-Converter. Allerdings habe ich da nur einen relativ kleinen
Bootloader drin. Die Hauptfirmware bootet von SD-Karte. Ein
Microcontroller mit 1MByte internem Ram fuehlt sich im Prinzip wie ein
alter DOS-Rechner an.

Ein Nachteil muss man aber leider zugeben. Der gcc fuer den SH2
funktioniert zwar gut und zuverlaessig, schliesslich ist die SH2
Unterstuetzung relativ alt und die SH2 sind in Japan sehr verbreitet,
allerdings ist der Code vom Renesas Compiler wenigstens doppelt so
schnell. Vermutlich weil der Compiler von Renesas speziel darauf
ausgerichtet ist die Superscalaritaet zu nutzen. Der Prozessor fuehrt
zwei Assemblerbefehle gleichzeitig aus wenn sie in der richtigen
Reihenfolge im Code stehen. Aber schnell ist der Controller immer
noch. Der dekodiert bei mir problemlos 320kbit MP3 in Software. :)

Olaf

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

#218561

Olaf Kaluza <olaf@criseis.ruhr.de> wrote:
>Marc Santhoff <m.santhoff@t-online.de> wrote:


> >Irgendwas, das von gcc unterstützt wird, dir gefällt und die sonstigen
> >Anforderungen erfüllt.

>Das reicht ihm aber nicht. Natuerlich kann man auf jeder beliebigen
>Linuxhardware einen gcc uebersetzen und damit fuer so gut wie alles
>entwickeln. Aber er muss seinen Code ja noch mindestens auf den
>Microcontroller bringen, besser noch einen funktionierenden Debugger
>haben. 
>Reinflashen sollte mit jedem Controller gehen der einen Bootloader
>fuer RS232 unterstuetzt. (das machen viele) 

Das wäre für mich auch ein Auswahlkriterium. Dann kann man sich zur
Not selber was zusammenfrickeln. Die Bootloader sind meist sehr gut
dokumentiert.

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

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

#218544

Marc Santhoff <m.santhoff@t-online.de> wrote:
> <usenet@teply.info> schrieb:
> 
>> Ich bin also auf der Suche nach a) einem Software-Toolset, das auch
> 
> gcc + Eclipse (o.ä., je nach Neigung) oder vi, ed und Makefiles.
> Sourcecode ist Text.
> 
Dieser Teil der Entwicklung ist mir soweit geläufig und unterscheidet
sich nicht von Entwicklung auf "richtigen" Computern.  Für mich
tendenziell vim+make, wenn es einen echten Mehrwert bringt meinetwegen
auch Eclipse. Aber dann muss das Kompilat ja noch in die Zielhardware 
kommen...

>> unter Linux auf nicht-x86 einsetzbar ist, und b) nach nem guenstigen
>> Entwicklungssystem auf der Hardware-Seite. Was wuerdet Ihr empfehlen?
> 
> Irgendwas, das von gcc unterstützt wird, dir gefällt und die sonstigen
> Anforderungen erfüllt.
> 
Das wäre der einfache Part, gcc übersetzt ja für fast alles was halbwegs
ne 1 von ner 0 unterscheiden kann. Da fehlt aber mindestens noch der 
Transfer ins interne Flash und handhabbares debugging.

Als ich mich zuletzt mit soetwas beschäftigt habe, habe ich sowohl in der 
Firma als auch in der Uni bereits fertige Windows-Rechner mit der 
Entwicklungsumgebung und debugger vorgefunden, konnte also direkt 
loslegen. Die Rahmenbedingungen sind jetzt aber anders, Keil und
Konsorten wären auf meinen Rechnern nichteinmal lauffähig, und
Debug-Hardware ist auch (noch) nicht da. Kernanforderung an die
Entwicklungsumgebung ist Benutzbarkeit mit meinen Rechnern, und das
schließt de facto alles aus, was nur als Binärpaket vorliegt. Für Linux
auf PowerPC (Als Entwicklungsrechner) muß ich _immer_ den Compiler
anwerfen.

> Z.B.:
> 
> Cortex-Mx sind recht komplex für den Einstieg, aber verbreitet, von
> ganz klein bis ziemlich fett zu bekommen.
> 
> Frühere ARM, ARM7(TDMI), ARM9(26) sind etwas überschaubarer, Abkündigung
> ist aber zu befürchten (oder schon passiert?).
> 
> Atmel AVR sind handlich, verbreitet aber etwas "altmodisch", aussterben
> werden die IMHO so schnell nicht, aber recht begrenzt in Sachen RAM
> und Skalierbarkeit nach oben.
> 
> PIC hat teils hübsche Eingeschaften, ist aber irgendwie ein Überbleibsel
> aus Zeiten kurz nach 6502, aber noch beliebt.
> 
> Alles sehr subjektiv natürlich...
>
Aus ungefähr den erwähnten Gründen hab' ich mir AVR, klassische PIC und ARM
vor der Cortex-Serie nicht weiter angeschaut, die scheinen mir doch arg
eng oder aber von Obsoleszenz bedroht. Was nützt einem ne schöne
Umgebung, wenn die Anwendung nicht reinpasst oder man keine Hardware
mehr bekommt...

Ähnliches befürchte ich für 68k/Coldfire und S08/S12, da das irgendwie 
nicht ins Portfolio bei Qualcomm reinzupassen scheint. Und nen potentiellen 
Käufer für diese Sparte sehe ich auch nicht, die üblichen Verdächtigen
haben bereits alle komplette Controllerfamilien. Ich fänd's richtig 
gut, wenn ich mich hier irre, denn mit beiden habe ich gerne gearbeitet.

Aus dem Angebot von digikey bleibt da nicht mehr so viel übrig: Am
unteren Ende der Preisskala findet sich mit ethernet fast nur
ARM-Geraffel gefolgt von MIPS und hier und da mal vereinzelt was anderes
wie AVR32 oder Coldfire. Bei den Entwicklungsboards mit ethernet wird die 
Luft schon recht dünn, das sind nur noch eine Handvoll mit Cortex-M oder
MIPS32. Ohne Ethernet sind es mal schlappe zwei Größenordnungen mehr
Angebot, und für einen Teil der Netzwerkanwendungen müsste ich sowieso
basteln mit externem PHY mit Hardware-Timestamping und Synchronem
Ethernet, so daß das nicht unbedingt ein Kriterium sein muß.

Gruß,
Florian

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

#218551

Am Wed, 14 Dec 2016 23:12:49 +0100 schrieb Florian Teply:

>  Kernanforderung an die
> Entwicklungsumgebung ist Benutzbarkeit mit meinen Rechnern

Vielleicht sollte man darüber noch einmal nachdenken und das sinnvoll
aufweichen?

Lutz

-- 
Mit unseren Sensoren ist der Administrator informiert, bevor es Probleme im 
Serverraum gibt: preiswerte Monitoring Hard- und Software-kostenloses Plugin 
auch für Nagios - Nachricht per e-mail,SMS und SNMP: http://www.messpc.de
Messwerte nachträgliche Wärmedämmung http://www.messpc.de/waermedaemmung.php

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

#218562

Lutz Schulze <lschulze@netzwerkseite.de> wrote:
>Am Wed, 14 Dec 2016 23:12:49 +0100 schrieb Florian Teply:

>>  Kernanforderung an die
>> Entwicklungsumgebung ist Benutzbarkeit mit meinen Rechnern

>Vielleicht sollte man darüber noch einmal nachdenken und das sinnvoll
>aufweichen?

Das würde ich auch vorschlagen. Pollin 750 040 für 111 EUR wäre wohl
eine brauchbare Plattform. Das installierte Win 7 Pro kann man durch
ein Linux ersetzen oder zumindest die Windows Partition shrinken.
Dann wird die Auswahl an Entwicklungsumgebungen schlagartig grösser
und auch die Wahrscheinlichkeit, bei Problemen in Foren Hilfe zu erhalten.

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

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

#218563

Peter Heitzer wrote:
> Lutz Schulze <lschulze@netzwerkseite.de> wrote:
>> Am Wed, 14 Dec 2016 23:12:49 +0100 schrieb Florian Teply:
> 
>>>  Kernanforderung an die
>>> Entwicklungsumgebung ist Benutzbarkeit mit meinen Rechnern
> 
>> Vielleicht sollte man darüber noch einmal nachdenken und das sinnvoll
>> aufweichen?
> 
> Das würde ich auch vorschlagen. Pollin 750 040 für 111 EUR wäre wohl
> eine brauchbare Plattform.

Ein Komplett-PC von Pollin? Für Boards würde ich eher da gucken:

http://www.olimex.com, z.B. die OLinuXino boards

http://shop.embedded-projects.net, z.B. GNUBLIN system

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

#218565

Edzard Egberts <news@edzeg.net> wrote:
>Peter Heitzer wrote:
>> Lutz Schulze <lschulze@netzwerkseite.de> wrote:
>>> Am Wed, 14 Dec 2016 23:12:49 +0100 schrieb Florian Teply:
>> 
>>>>  Kernanforderung an die
>>>> Entwicklungsumgebung ist Benutzbarkeit mit meinen Rechnern
>> 
>>> Vielleicht sollte man darüber noch einmal nachdenken und das sinnvoll
>>> aufweichen?
>> 
>> Das würde ich auch vorschlagen. Pollin 750 040 für 111 EUR wäre wohl
>> eine brauchbare Plattform.

>Ein Komplett-PC von Pollin? Für Boards würde ich eher da gucken:

>http://www.olimex.com, z.B. die OLinuXino boards

>http://shop.embedded-projects.net, z.B. GNUBLIN system

Ich bezog mich auf die verwendeten Rechner, auf denen die Entwicklungssoftware
laufen soll. D.h. seine PPC Rechner (vermutlich ältere Macs) durch einen 
Rechner mit x86 CPU zu ergänzen.

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

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

#218567

Florian Teply <usenet@teply.info> schrieb:

> Aus dem Angebot von digikey bleibt da nicht mehr so viel übrig: Am
> unteren Ende der Preisskala findet sich mit ethernet fast nur
> ARM-Geraffel gefolgt von MIPS und hier und da mal vereinzelt was
> anderes wie AVR32 oder Coldfire. Bei den Entwicklungsboards mit
> ethernet wird die Luft schon recht dünn, das sind nur noch eine
> Handvoll mit Cortex-M oder MIPS32. Ohne Ethernet sind es mal schlappe
> zwei Größenordnungen mehr Angebot, und für einen Teil der
> Netzwerkanwendungen müsste ich sowieso basteln mit externem PHY mit
> Hardware-Timestamping und Synchronem Ethernet, so daß das nicht
> unbedingt ein Kriterium sein muß.

Dann schau doch mal da, ob es eine fetige Version für deinen
Entwicklungsrechner gibt bzw. ob die Quellen im Repo deines Linux sind
oder eben sich mit vertretbarem Aufwand selbst übersetzen lassen:

http://openocd.org/

Die Unterstützung für Flasher-Hardware und Protokolle ist eigentlich
sehr breit. Benutzen tu ich es selbst nicht, daher keine Empfehlung
oder Tipps. Bin unter FreeBSD mit avrdude unterwegs bzw. für STM32
benutze ich Windows wg. der Tools vom Hersteller.

Btw., für WLAN kann man auf ESP8266 zurückgreifen, kleine Module mit
selbst genug Rechenpower aber wenigfreien I/O.

Für kleine CPU bzw. SoC ist auch das schon genannte Ethernut, das
eigentlich NutOS heißt, einen Blick wert.

http://ethernut.de/


HTH,
Marc

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

#218576

Marc Santhoff <m.santhoff@t-online.de> wrote:
> Florian Teply <usenet@teply.info> schrieb:
> 
>> Aus dem Angebot von digikey bleibt da nicht mehr so viel übrig: Am
>> unteren Ende der Preisskala findet sich mit ethernet fast nur
>> ARM-Geraffel gefolgt von MIPS und hier und da mal vereinzelt was
>> anderes wie AVR32 oder Coldfire. Bei den Entwicklungsboards mit
>> ethernet wird die Luft schon recht dünn, das sind nur noch eine
>> Handvoll mit Cortex-M oder MIPS32. Ohne Ethernet sind es mal schlappe
>> zwei Größenordnungen mehr Angebot, und für einen Teil der
>> Netzwerkanwendungen müsste ich sowieso basteln mit externem PHY mit
>> Hardware-Timestamping und Synchronem Ethernet, so daß das nicht
>> unbedingt ein Kriterium sein muß.
> 
> Dann schau doch mal da, ob es eine fetige Version für deinen
> Entwicklungsrechner gibt bzw. ob die Quellen im Repo deines Linux sind
> oder eben sich mit vertretbarem Aufwand selbst übersetzen lassen:
> 
> http://openocd.org/
> 
Das kompiliert gerade. Zusammen mit DDD, gcc und den anderen tools.
Dauert halt ein bischen, der Rechner ist nicht dewr neueste, aber man
kann ja nebenbei noch im Usenet schreiben ;-)

> Die Unterstützung für Flasher-Hardware und Protokolle ist eigentlich
> sehr breit. Benutzen tu ich es selbst nicht, daher keine Empfehlung
> oder Tipps. Bin unter FreeBSD mit avrdude unterwegs bzw. für STM32
> benutze ich Windows wg. der Tools vom Hersteller.
> 
Mal sehen was hier sonst noch für Empfehlungen auftauchen.

Gruß,
Florian

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

#218578

On 2016-12-14, Florian Teply <usenet@teply.info> wrote:
> Aus ungefähr den erwähnten Gründen hab' ich mir AVR, klassische PIC und ARM
> vor der Cortex-Serie nicht weiter angeschaut, die scheinen mir doch arg
> eng oder aber von Obsoleszenz bedroht. Was nützt einem ne schöne
> Umgebung, wenn die Anwendung nicht reinpasst oder man keine Hardware
> mehr bekommt...
>
> Ähnliches befürchte ich für 68k/Coldfire und S08/S12, da das irgendwie 
> nicht ins Portfolio bei Qualcomm reinzupassen scheint. Und nen potentiellen 

Die waren IMHO auch vor NXP/Qualcomm schon nahezu tot - Freescale hat bei
den kleinen Controllern seit längerem IIRC fast nur noch auf der ARM-Schiene
neues herausgebracht.

> Aus dem Angebot von digikey bleibt da nicht mehr so viel übrig: Am
> unteren Ende der Preisskala findet sich mit ethernet fast nur
> ARM-Geraffel gefolgt von MIPS und hier und da mal vereinzelt was anderes
> wie AVR32 oder Coldfire. Bei den Entwicklungsboards mit ethernet wird die 
> Luft schon recht dünn, das sind nur noch eine Handvoll mit Cortex-M oder
> MIPS32.

Ich würde STM32F4xx (oder 32F7xx? Ich habe heute ein STM32F746-Discovery-Kit
auf den Tisch bekommen) oder einen LPC mit Ethernet-MAC empfehlen.  Beide
laufen mit den üblichen GNU-Tools und OpenOCD als Debugger/Flash-Tool.

Bei MIPS habe ich keine Erfahrungen - manche werden von OpenOCD per JTAG
unterstützt.

cu
Michael

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

#218609

Michael Schwingen <news-1457978346@discworld.dascon.de> wrote:
> On 2016-12-14, Florian Teply <usenet@teply.info> wrote:
>> Aus ungefähr den erwähnten Gründen hab' ich mir AVR, klassische PIC und ARM
>> vor der Cortex-Serie nicht weiter angeschaut, die scheinen mir doch arg
>> eng oder aber von Obsoleszenz bedroht. Was nützt einem ne schöne
>> Umgebung, wenn die Anwendung nicht reinpasst oder man keine Hardware
>> mehr bekommt...
>>
>> Ähnliches befürchte ich für 68k/Coldfire und S08/S12, da das irgendwie 
>> nicht ins Portfolio bei Qualcomm reinzupassen scheint.
> 
> Die waren IMHO auch vor NXP/Qualcomm schon nahezu tot - Freescale hat bei
> den kleinen Controllern seit längerem IIRC fast nur noch auf der ARM-Schiene
> neues herausgebracht.
>
Stümmt, irgendwie hat sich da seit Motorola-Zeiten kaum mehr was getan. PPC 
wurde ja wenigstens nebenbei von IBM getrieben und später dann auch von der 
anderen Bude auf deren Name ich gerade nicht komme, irgendwas mit A...

68k wurde zwar noch auf Coldfire aufgebohrt, aber das wurde anscheinend von
der Kommunikationssparte und deren Kunden getrieben und wurde eher halbherzig 
gemacht. Dabei find ich den Maschinencode da recht elegant :-(

>> Aus dem Angebot von digikey bleibt da nicht mehr so viel übrig: Am
>> unteren Ende der Preisskala findet sich mit ethernet fast nur
>> ARM-Geraffel gefolgt von MIPS und hier und da mal vereinzelt was anderes
>> wie AVR32 oder Coldfire. Bei den Entwicklungsboards mit ethernet wird die 
>> Luft schon recht dünn, das sind nur noch eine Handvoll mit Cortex-M oder
>> MIPS32.
> 
> Ich würde STM32F4xx (oder 32F7xx? Ich habe heute ein STM32F746-Discovery-Kit
> auf den Tisch bekommen) oder einen LPC mit Ethernet-MAC empfehlen.  Beide
> laufen mit den üblichen GNU-Tools und OpenOCD als Debugger/Flash-Tool.
> 
Die zwei stehen bei mir momentan auch recht weit oben auf der Liste. NXP 
wurde traditionell schon recht gut von Open Source tools unterstützt, und 
ST scheint da seit kurzem auch ein wenig Energie zu investieren.

> Bei MIPS habe ich keine Erfahrungen - manche werden von OpenOCD per JTAG
> unterstützt.
> 
Na mal sehen. Irgendwie muss das doch gehen, ein Haufen WLAN-Router haben 
doch MIPS-prozessoren drin. Ist dann zwar mit Linux obendrauf, aber das 
macht ja nix...

Gruß,
Florian

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

#218628

On 2016-12-16, Florian Teply <usenet@teply.info> wrote:
> 68k wurde zwar noch auf Coldfire aufgebohrt, aber das wurde anscheinend von
> der Kommunikationssparte und deren Kunden getrieben und wurde eher halbherzig 
> gemacht. Dabei find ich den Maschinencode da recht elegant :-(

Ich habe damals (~2000) gerne auf SH3/SH4 gearbeitet, das kommt einem vor
wie eine RISC-Version des 68k-Befehlssatzes.

>> Ich würde STM32F4xx (oder 32F7xx? Ich habe heute ein STM32F746-Discovery-Kit
>> auf den Tisch bekommen) oder einen LPC mit Ethernet-MAC empfehlen.  Beide
>> laufen mit den üblichen GNU-Tools und OpenOCD als Debugger/Flash-Tool.
>> 
> Die zwei stehen bei mir momentan auch recht weit oben auf der Liste. NXP 
> wurde traditionell schon recht gut von Open Source tools unterstützt, und 
> ST scheint da seit kurzem auch ein wenig Energie zu investieren.

Die älteren LPC-Sachen waren nicht so toll - das CodeRed-Geraffel lief wegen
binary-only Debug-Tool und proprietärer Debug-Hardware auf den Evalboards
nur unter manchen X86-Linux-Versionen (d.h. z.B. nicht auf Debian). Ich habe
damals einen ST-Link samt OpenOCD benutzt, um die LPC1768 zu programmieren,
und das LPC-Interface in die Tonne getreten.

Inzwischen sollte das besser geworden sein.

> Na mal sehen. Irgendwie muss das doch gehen, ein Haufen WLAN-Router haben 
> doch MIPS-prozessoren drin. Ist dann zwar mit Linux obendrauf, aber das 
> macht ja nix...

TP-Link & Co mit älteren Atheros/QCA-Chipsätzen (AR933x) sollten gut
unterstützt werden. Wenn Du Dir eine serielle Console 'dranfädelst und den
u-boot im Flash nicht plättest, kommst Du ohne Programmierkabel aus.

Ich habe mir zum Spaß mal einen von denen hier besorgt:

https://wiki.openwrt.org/toh/unbranded/a5-v11?s

kompletter Rechner mit Ethernet, WLAN und USB-Host (das war der Anreiz, das
Teil zu besorgen - die Idee war, da einen ST-Link anzustecken) für ca.  10
EUR.  OpenWRT läuft, aber das Flash ist sehr knapp.

cu
Michael

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

#218581

<usenet@teply.info>:

> Nun hab ich hier ein paar eher spezielle Rahmenbedingungen: die zur
> Entwicklung zur Verfuegung stehenden Rechner haben weder Windows, noch ne
> x86-kompatible CPU, sondern laufen unter Linux auf PowerPC. Damit fallen 
> gefuehlt 99% der von den jeweiligen Herstellern propagierten und in 
> Binaerform unter Volk gestreuten Entwicklungsumgebungen schonmal komplett 
> aus, da in diesem Hardware/Software-Kontext nicht lauffaehig.

PowerPC? Gibts sowas überhaupt noch? Was findest Du an x86 schlecht - sofern 
Linux drauf läuft?
 
> Ich bin also auf der Suche nach a) einem Software-Toolset, das auch
> unter Linux auf nicht-x86 einsetzbar ist, und b) nach nem guenstigen
> Entwicklungssystem auf der Hardware-Seite. Was wuerdet Ihr empfehlen?

Mal ein Tipp am Rande. Leg Dich nicht zu sehr fest. Man muss auch mal 
Kompromisse machen. Insbesondere bei der Festlegung der Entwicklungsumgebung 
auf PowerPC und nicht x86 - wieso bis Du da so festgelegt?
Ich würde das Hauptaugenmerk auf die Leistungsfähigkeit der Controllerfamilie 
legen und wie gross die Community dazu ist, insbesondere sollte auch alle 
Libs quelloffen sein, da stimm ich Dir zu.  Da kommt heutzutage insbesondere 
32bit ARM infrage, selbst für kleinste Projekte stören die 32bit ihmo nicht. 
Mit dem Rest dann irgendwie versuchen zu leben - und sei es ein extra 
Notebook mit x86 auf dem die Entwicklungsumgebung läuft, es muss ja nicht das 
unsägluiche Win**Üüü sein, oft läuft ja auch einiges dank gcc und Co auf 
Linux.

M.
-- 

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

#218610

Matthias Weingart <mwnews@pentax.boerde.de> wrote:
> <usenet@teply.info>:
> 
>> Nun hab ich hier ein paar eher spezielle Rahmenbedingungen: die zur
>> Entwicklung zur Verfuegung stehenden Rechner haben weder Windows, noch ne
>> x86-kompatible CPU, sondern laufen unter Linux auf PowerPC. Damit fallen 
>> gefuehlt 99% der von den jeweiligen Herstellern propagierten und in 
>> Binaerform unter Volk gestreuten Entwicklungsumgebungen schonmal komplett 
>> aus, da in diesem Hardware/Software-Kontext nicht lauffaehig.
> 
> PowerPC? Gibts sowas überhaupt noch? Was findest Du an x86 schlecht - 
> sofern Linux drauf läuft?
>  
Neu gibt's PPC praktisch nur noch als Industrie-Hardware, das ist richtig. 
Seit Apple auf x86 umgestiegen ist gibts da nix mehr auf dem Consumer-Markt.
Aber: das gibt es tatsächlich noch, die Hardware läuft und läuft und läuft...
x86 find' ich nicht prinzipiell schlecht, hab' ich nur nicht zur Verfügung.
Prinzipiell könnte ich auch nach ner Entwicklungsumgebung suchen, die unter 
MacOS 6 auf 68k läuft, das dürfte aber _wirklich_ aussichtslos sein.

>> Ich bin also auf der Suche nach a) einem Software-Toolset, das auch
>> unter Linux auf nicht-x86 einsetzbar ist, und b) nach nem guenstigen
>> Entwicklungssystem auf der Hardware-Seite. Was wuerdet Ihr empfehlen?
> 
> Mal ein Tipp am Rande. Leg Dich nicht zu sehr fest. Man muss auch mal 
> Kompromisse machen. Insbesondere bei der Festlegung der 
> Entwicklungsumgebung auf PowerPC und nicht x86 - wieso bis Du da so 
> festgelegt?

Nun, da steht halt hier Hardware rum, x86 hab' ich privat nicht, und mein 
Arbeitgeber dürfte sich eher wenig erfreut zeigen wenn ich meine Arbeitszeit 
mit soetwas verdaddele.

> Ich würde das Hauptaugenmerk auf die Leistungsfähigkeit der Controllerfamilie 
> legen und wie gross die Community dazu ist, insbesondere sollte auch alle 
> Libs quelloffen sein, da stimm ich Dir zu.  Da kommt heutzutage insbesondere 
> 32bit ARM infrage, selbst f?r kleinste Projekte st?ren die 32bit ihmo nicht. 
> Mit dem Rest dann irgendwie versuchen zu leben - und sei es ein extra 
> Notebook mit x86 auf dem die Entwicklungsumgebung l?uft, es muss ja nicht das 
> uns?gluiche Win**??? sein, oft l?uft ja auch einiges dank gcc und Co auf 
> Linux.
> 
Windows kommt mir schon aus Prinzip nicht ins Haus. Ich bin die letzten 30 
Jahre privat ohne Windows ausgekommen, da muß ich jetzt nicht damit anfangen.
Über ne x86-Maschine würde ich nachdenken wenn es nicht anders geht, aber 
solange die Tools Open Source sind, ist das nicht nötig, das kompiliert IDR
auch auf anderen Architekturen wunderbar.

Letztendlich liegt das Augenmerk wie Du erwähnst zum größten Teil auf den 
Möglichkeiten und der einfachen Verfügbarkeit der Hardware sowie der nötigen 
Libraries. Bezüglich Community, nun, das herauszufinden ist auch Intention 
dieses Threads. Soweit ich das bis jetzt überblicke, scheint vieles in 
Richtung ARM Cortex-M (NXP LPCxxx or ST STM32) zu deuten, mit ein paar 
Minderheitsvoten für eher exotische Architekturen. Persönlich bin ich ja für 
exotische Hardware zu haben, sonst hätte ich ja schon lange x86 zuhause ;-) 

Softwareseitig scheint sich fürs Debugging OpenOCD herauszukristallisieren, 
evtl. auch mit Unterstützung durch DDD. Und natürlich die GNU Tools...

Basierend darauf werd' ich mich nun nach Hardware (Eval-Board, JTAG-Adapter) 
umsehen müssen, und dann das eine mit dem anderen abgleichen.

Gruß,
Florian

[toc] | [prev] | [standalone]

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

Back to top | Article view | de.sci.electronics

csiph-web