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

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

Buchtip: Messtechnik mit einem ARM Cortex M0-Mikrocontroller

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

Contents

  Buchtip: Messtechnik mit einem ARM Cortex M0-Mikrocontroller sailcamvollmuell@gmx.de (Andreas Schmidt) - 2017-04-28 11:33 +0200
    Re: Buchtip: Messtechnik mit einem ARM Cortex M0-Mikrocontroller Hermann Riemann <nospam.ng@hermann-riemann.de> - 2017-04-28 12:02 +0200
    Re: Buchtip: Messtechnik mit einem ARM Cortex M0-Mikrocontroller Joerg Niggemeyer <joerg.niggemeyer@nucon.de> - 2017-04-28 12:28 +0100
      Re: Buchtip: Messtechnik mit einem ARM Cortex M0-Mikrocontroller Rafael Deliano <rafael_deliano@arcor.de> - 2017-04-28 17:44 +0200
        Re: Buchtip: Messtechnik mit einem ARM Cortex M0-Mikrocontroller Michael Schwingen <news-1457978346@discworld.dascon.de> - 2017-04-28 18:59 +0000
          Re: Buchtip: Messtechnik mit einem ARM Cortex M0-Mikrocontroller Rafael Deliano <rafael_deliano@arcor.de> - 2017-04-29 06:43 +0200
            Lizenzen (was: Buchtip: Messtechnik mit einem ARM Cortex M0-Mikrocontroller) Michael Bäuerle <michael.baeuerle@gmx.net> - 2017-04-29 18:46 +0000
              Re: Lizenzen Rafael Deliano <rafael_deliano@arcor.de> - 2017-04-30 08:09 +0200
                Re: Lizenzen Marc Santhoff <m.santhoff@t-online.de> - 2017-05-01 14:15 +0200
                  Re: Lizenzen Matthias Weingart <mwnews@pentax.boerde.de> - 2017-05-02 07:57 +0000
                    Re: Lizenzen Marc Santhoff <m.santhoff@t-online.de> - 2017-05-02 16:53 +0200
            Re: Buchtip: Messtechnik mit einem ARM Cortex M0-Mikrocontroller Michael Schwingen <news-1457978346@discworld.dascon.de> - 2017-05-01 11:17 +0000
              Re: Buchtip: Messtechnik mit einem ARM Cortex M0-Mikrocontroller Rafael Deliano <rafael_deliano@arcor.de> - 2017-05-01 14:26 +0200
            Re: Buchtip: Messtechnik mit einem ARM Cortex M0-Mikrocontroller Joerg Niggemeyer <joerg.niggemeyer@nucon.de> - 2017-05-11 18:20 +0100
        Re: Buchtip: Messtechnik mit einem ARM Cortex M0-Mikrocontroller Joerg Niggemeyer <joerg.niggemeyer@nucon.de> - 2017-05-02 11:33 +0100
      Re: Buchtip: Messtechnik mit einem ARM Cortex M0-Mikrocontroller sailcamvollmuell@gmx.de (Andreas Schmidt) - 2017-05-03 22:58 +0200
        Re: Buchtip: Messtechnik mit einem ARM Cortex M0-Mikrocontroller Joerg Niggemeyer <joerg.niggemeyer@nucon.de> - 2017-05-04 09:59 +0100

#226801 — Buchtip: Messtechnik mit einem ARM Cortex M0-Mikrocontroller

Hallo,

bin Neuling beim µC-Programmieren in C und im µC sowieso. Habe einen NXP
LPC1115 (ARM Cortex-M0) mit Debug-Einheit vorliegen und möchte nun
Programmieren lernen mit ein paar kleinen Meßtechnik-Aufgaben. 

Im Moment suche ich Literatur, womit ich mir das im Selbststudium
beibringen kann. Im Netz habe ich kürzlich ein Buch aus dem
Franzis-Verlag von 2004 gefunden, was mir etwas überholt scheint. Hat
einer in der Runde ein paar Hinweise wo ich verständliche Info (kann
auch in Englisch sein) finde? Es kann auch etwas weiter gefaßt um
"Messen, Steuern, Regeln" gehen.

Danke für Eure Infos,

Andreas 

[toc] | [next] | [standalone]

#226806

Am 28.04.2017 um 11:33 schrieb Andreas Schmidt:

> bin Neuling beim µC-Programmieren in C und im µC sowieso. Habe einen NXP
> LPC1115 (ARM Cortex-M0) mit Debug-Einheit vorliegen und möchte nun
> Programmieren lernen mit ein paar kleinen Meßtechnik-Aufgaben.

Programmieren lernen mit Meßtechnik-Aufgaben
dürfte mit raspberry pi bzw. Arduino
nach meiner Einschätzung einfacher gehen.

> Im Moment suche ich Literatur, womit ich mir das im Selbststudium
> beibringen kann.

Vielleicht ist das Buch ARM Cortex-M3 Mikrocontroller
2014 mitp ISBN 978-3-8266-9475-2 hilfreich.

Wobei
https://blogspot.tenettech.com/cortex-m0-vs-cortex-m3.html
https://de.wikipedia.org/wiki/ARM_Cortex-M
Hinweise auf m3 und m0 liefern,
die noch in den IDEs (hoffentlich) eingestellt werden müssten.

Hermann
    dem noch praktische Erfahrung mit Mikrocontroller fehlen.

-- 
http://www.hermann-riemann.de

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

#226813

In message <1n56vqu.1bw8byv1k70p8gN%sailcamvollmuell@gmx.de>
          sailcamvollmuell@gmx.de (Andreas Schmidt) wrote:

> Hallo,

> bin Neuling beim µC-Programmieren in C und im µC sowieso. Habe einen NXP
> LPC1115 (ARM Cortex-M0) mit Debug-Einheit vorliegen und möchte nun
> Programmieren lernen mit ein paar kleinen Meßtechnik-Aufgaben.

Moeglicherweise waere es besser, Du schaust nach einem
anderen Starterboard, wobei ARM sicherlich schon eine gute
Wahl ist. (Wenn M0, dann lieber M0+ wegen besserer Debug Features.)

https://developer.mbed.org/platforms/

z.B. FRDM-KL25Z

> Im Moment suche ich Literatur, womit ich mir das im Selbststudium
> beibringen kann. Im Netz habe ich kürzlich ein Buch aus dem
> Franzis-Verlag von 2004 gefunden, was mir etwas überholt scheint. Hat
> einer in der Runde ein paar Hinweise wo ich verständliche Info (kann
> auch in Englisch sein) finde? Es kann auch etwas weiter gefaßt um
> "Messen, Steuern, Regeln" gehen.

Buecher sind wohl nicht mehr so in Mode, da das meiste im Netz zu 
finden ist.

Fuer den ersten mbed gibt es z.B. das Buch:
Fast and Effective Embedded Systems Design
Applying the ARM mbed
von 2012

95% vom Inhalt steht auch Online zur Verfügung - ich selber lese ganz 
gerne noch in einem normalen Buch herum ;-)



> Danke für Eure Infos,

> Andreas



-- 
mit freundlichen Gruessen/ best regards Joerg Niggemeyer
WEB: http://www.nucon.de    http://www.led-temperature-protection.com

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

#226820

> z.B. FRDM-KL25Z

   Habe ich ca. 5 Stück in mehr oder weniger gefledertem Zustand
rumliegen. Länger mit dem Teil Zeit verbracht als mir lieb
ist.
   Das Board hat einen zweiten Controller mit Firmware von P&E
das die JTAG/SWD-Debugschnittstelle auf USB machen soll. Aber
letztlich erwies sich die Variante als so verkrüppelt daß ich
mir einen Segger gekauft habe. Der tut.
   Freescale preist für das Board seine eigene GCC Benutzer-
oberfläche an. Aber die ist bezüglich Integration von Debugger
auch Müll. Also bin ich auf Keil übergegangen: leicht erlernbar,
leicht bedienbar, funktiert gut. Aber wenn man über das
kostenlose 32kByte Limit kommt wäre der extrem teuer.
    Ich benutzte zwar Motorola seit anno 68HC05 aber die sind
auf stark absteigendem Ast.

An Literatur ist
Yiu "The Definitive Guide to ARM® Cortex®-M0 and Cortex-M0+ Processors"
hilfreich. Das meiste muß man sich trotzdem im www zusammensuchen.
https://www.amazon.de/Definitive-Guide-Cortex-M0-Cortex-M0-Processors/dp/0128032774/ref=sr_1_1?ie=UTF8&qid=1493393584&sr=8-1&keywords=cortex+M0%2B

 > bin Neuling beim µC-Programmieren in C und im µC sowieso.
 > und möchte nun Programmieren lernen

   Ich würde mir mal ansehen wie man einen Portpin auf einem
Controller wie 68HC08 schaltet: Bit im DDR auf Output und dann
Bit im Portregister schalten. Das sind zwei Assemblerbefehle.
   Und dann sollte man sich ansehen wie das in C auf Cortex M0+
aussieht. Faktor 10 mehr Gewürge.
D.h. als Einstieg ungeeignet. 8 Bit ist da besser.

MfG  JRD

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

#226831

On 2017-04-28, Rafael Deliano <rafael_deliano@arcor.de> wrote:
>> z.B. FRDM-KL25Z

>    Das Board hat einen zweiten Controller mit Firmware von P&E
> das die JTAG/SWD-Debugschnittstelle auf USB machen soll. Aber
> letztlich erwies sich die Variante als so verkrüppelt daß ich
> mir einen Segger gekauft habe. Der tut.

Ich habe keine Erfahrungen mit dem Board, aber es sollte eine
CMSIS-DAP-Firmware für das Debuginterface geben:

https://mcuoneclipse.com/2013/05/17/cmsis-dap-with-iar-and-the-kl25z-freedom-board/
https://developer.mbed.org/handbook/Firmware-FRDM-KL25Z

>    Freescale preist für das Board seine eigene GCC Benutzer-
> oberfläche an. Aber die ist bezüglich Integration von Debugger
> auch Müll. Also bin ich auf Keil übergegangen: leicht erlernbar,
> leicht bedienbar, funktiert gut. Aber wenn man über das
> kostenlose 32kByte Limit kommt wäre der extrem teuer.
>     Ich benutzte zwar Motorola seit anno 68HC05 aber die sind
> auf stark absteigendem Ast.

Bei Freescale/NXP ist im Moment mit den IDEs ziemliches Chaos - auf der
Schulung zum FRDM-KW41Z letztens sagte man, daß das alles in einer neuen,
gemeinsamen IDE zusammengefasst werden soll, aber da knirscht es noch.

Ich empfehle generell (für alle Cortex-XX) eine nackte
gcc/gdb/make/openocd-Toolchain, wer's braucht mit Eclipse (aber die normale,
nicht die von einem der Chiphersteller).  Das tut hier problemlos mit ST,
NXP, Atmel und TI-Chips.

https://gnuarmeclipse.github.io/

gibt einen guten Startpunkt.

Für den allerersten Einstieg installiert man wohl besser doch die
Hersteller-Tools, um einmal deren Beispiele durchzuspielen, sonst ist es
knifflig, die richtigen Compilersettings und Flags für deren Code zu finden,
aber danach löst man sich am besten von deren Beispiel-Code und startet mit
einem nackten Projekt, wo man stückweise das an Initialisierung 'reinzieht,
was man braucht. Beim Ansehen der Hersteller-HALs/Treiber bekomme ich
regelmäßig Ausschlag ...

cu
Michael

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

#226834

> Ich habe keine Erfahrungen mit dem Board, aber es sollte eine
> CMSIS-DAP-Firmware für das Debuginterface geben:
>
> https://mcuoneclipse.com/2013/05/17/cmsis-dap-with-iar-and-the-kl25z-freedom-board/
> https://developer.mbed.org/handbook/Firmware-FRDM-KL25Z

Es gibt das Original von P&E, verkrüppelt. Ich hab kein Problem
wenn P&E seine kostenpflichtigen Produkte verkaufen will, aber
dann sollten P&E oder Freescale explizit in der Dokumentation
darauf hinweisen daß und wie die FRDM-Firmware künstlich
"limitiert" wurde.
Es gibt ein nachladbare Firmware von Segger ( non-commercial-use )
und eine von Keil glaube ich ( non-commercial-use ) die jeweils
wohl tut. Das non-commercial war da das Hindernis für mich:
ich kann die FRDM-Boards letztlich nichtmal als Production-
programmer verwenden. Da wird also dann noch ein kleiner Segger
nötig.
Es gibt natürlich irgendwo eine kostenloses, halbtotes "open source"
Projekt der "community". Zero-support, debug it yourself, Jahre nach 
Ankündigung der kommerziellen Produkte verfügbar. Typisch "open source
Lizenz" ( die dann für kommerzielle Anwendung Pferdefuß haben kann ), 
nicht simpel altmodisch "public domain".

> Bei Freescale/NXP ist im Moment mit den IDEs ziemliches Chaos - auf der
> Schulung zum FRDM-KW41Z letztens sagte man, daß das alles in einer neuen,
> gemeinsamen IDE zusammengefasst werden soll, aber da knirscht es noch.

Bei Freescale fängt das Marketing ca. alle 2 Jahre was neues an, ohne
daß der alte Ansatz jemals zuende entwickelt wird. Es gibt ja auch
kaum bezahlte Entwickler die da viel machen würden: es ist kein
Produkt für das Kunde zahlt, sondern Marketingspielzeug. Das letzte 
echte in Vollversion kommerzielle Produkt von anno Motorola war wohl
code warrior.
Eclipse ist im Verhältnis zu Keil aufgeblasen und unübersichtlich. 
Gcc/gdb schlampig bis gar nicht integriert. Als RTOS und middleware wird 
noch gerne ein third party Produkt integriert. Der Anbieter
stirbt typisch nach ein paar Jahren oder es ist verkrüppelt oder es
ist noch nicht zuendeentwickelt oder Freescale findet bald darauf
was anderes was noch "cooler" ist. Derzeit ist CMSIS angesagt ...

> Ich empfehle generell (für alle Cortex-XX) eine nackte
> gcc/gdb/make/openocd-Toolchain, wer's braucht mit Eclipse (aber die normale,
> nicht die von einem der Chiphersteller).  Das tut hier problemlos mit ST,
> NXP, Atmel und TI-Chips.

Wenn man viel Zeit in Konfiguration der Tools investiert, mag man so 
glücklich werden. Aber der Ansatz scheidet für die meisten Firmen aus. 
Keil/ARM wiederum ist so gesalzen teuer, daß die meisten kleineren
Firmen damit auch nicht glücklich werden.

Der ganze ARM-Klimbim hat seinen Zenit bereits überschritten.
Derart komplexe Produkte brauchen irren Support. Der ist durch die 
$1-Controller nicht finanzierbar.

MfG JRD

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

#226847 — Lizenzen (was: Buchtip: Messtechnik mit einem ARM Cortex M0-Mikrocontroller)

Rafael Deliano wrote:
> 
> [...]
> Es gibt natürlich irgendwo eine kostenloses, halbtotes "open source"
> Projekt der "community". Zero-support, debug it yourself, Jahre nach 
> Ankündigung der kommerziellen Produkte verfügbar. Typisch "open source
> Lizenz" ( die dann für kommerzielle Anwendung Pferdefuß haben kann ), 
> nicht simpel altmodisch "public domain".

Man muss "public domain" (als Entwickler) halt wollen - und nein, das
war "früher" auch oft nicht der Fall. Damals hat man dann eben Sachen
wie "Shareware" genommen (wurde irgendwann vom Geiz getötet).
Die Bereitschaft seine Arbeit ohne Gegenleistung anderen zum Geldver-
dienen zu überlassen war früher wie heute begrenzt.

Statt "public domain" macht man heute BSD-Lizenz (nach dem Motto: mach
was du willst damit - auch kommerziell, aber nenne wenigstens den
Urheber).

Wem das nicht reicht der nimmt GPL (nach dem Motto: mach was du willst
damit, aber stelle es auch mir und anderen zur Verfügung, wenn du es
verändert weitergibst).

An beidem gibt es IMHO nichts auszusetzen.


BTW:
Normalerweise bekommt man nichts geschenkt. Vielleicht ist das ja auch
der Grund warum GNU/Linux (GPL) als OS erfolgreicher war als *BSD (alle
Lizenz-Varianten). Die Lizenz in ersterem Fall erzwang mehr geben und
nehmen, während im letzteren Fall den Code jeder gerne nahm, aber selbst
keinen schrieb (daher heute der technische Rückstand, der früher längst
nicht so groß war).

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

#226853 — Re: Lizenzen

> Die Bereitschaft seine Arbeit ohne Gegenleistung anderen zum Geldver-
> dienen zu überlassen war früher wie heute begrenzt.

Das sehe ich auch so.
Shareware war so ein Flop daß der Begriff inzwischen
aus dem Vokalbular verschwunden ist.
Aber, vgl. anderen thread

/ Tool zum visualisieren von Daten (RS232) OpenSource
/ http://www.logview.info/forum/index.php?pages/home/
/ LogView Studio ist Donationware ...
/ Kommerzielle Nutzung ist nur mit unserem
/ Einverständnis möglich.

Es hat sich halt schiefe Erwartungshaltung bei vielen
Anwendern ergeben. Das "Angebot" der Pseudo-Unternehmer
ist genauso schrottig.
   Was fehlt ist, dass man 300 EUR auf den Tisch legt und
und dann ein Programm mit ein paar Updates, Handbuch und
Support erhält.
"Visualisiern von Daten" kann so Zeug wie Labview sicher
auch, aber das ist nicht kosteneffektiv.

MfG  JRD

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

#226885 — Re: Lizenzen

Rafael Deliano <rafael_deliano@arcor.de> schrieb:

> > Die Bereitschaft seine Arbeit ohne Gegenleistung anderen zum
> > Geldver- dienen zu überlassen war früher wie heute begrenzt.
> 
> Das sehe ich auch so.
> Shareware war so ein Flop daß der Begriff inzwischen
> aus dem Vokalbular verschwunden ist.

Das klassische Kaufmodell hat sich aber auch irgendwie abgefressen.
Einmal kaufen und immer benutzen ernährt die Entwickler nicht.
Abo-Modelle sind erstmal die Konsequenz. Neben der Bindung an Windows
und dem Update-Zwang durch Rückwärts-Inkompatibilität natürlich.

> Es hat sich halt schiefe Erwartungshaltung bei vielen
> Anwendern ergeben.

Das der Gelegenheitsanwender, der einmal oder einmal im Jahr eine
Software benutzen muß, keine großen Beträge ausgeben möchte, ist doch
verständlich. Und das manch anderer sich dranhängt, auch wenn er damit
Geld verdient, irgendwie auch. Darüber hinaus ist Fairness wohl das
Problem, ein zunehmend historisch wirkender Wert.

> Was fehlt ist, dass man 300 EUR auf den Tisch legt und
> und dann ein Programm mit ein paar Updates, Handbuch und
> Support erhält.

Gibt es doch in vielen Bereichen noch, obwohl ich für
Datenvisualisierung keins aus den Gedächtnis kenne. Daqarta z.B. oder
anderes Thema XXE fallen mir spontan ein. Richtig gute Programme für
vergleichsweise wenig Geld und mit Updates, etc, pipapo.

Doch, Abacom fällt mir ein. Leider weiß ich nicht, ob man damit die
gestellte Aufgabe lösen kann.

Marc

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

#226904 — Re: Lizenzen

Marc Santhoff <m.santhoff@t-online.de>:

> Rafael Deliano <rafael_deliano@arcor.de> schrieb:
> 
>> > Die Bereitschaft seine Arbeit ohne Gegenleistung anderen zum
>> > Geldver- dienen zu überlassen war früher wie heute begrenzt.
>> 
>> Das sehe ich auch so.
>> Shareware war so ein Flop daß der Begriff inzwischen
>> aus dem Vokalbular verschwunden ist.
> 
> Das klassische Kaufmodell hat sich aber auch irgendwie abgefressen.
> Einmal kaufen und immer benutzen ernährt die Entwickler nicht.
> Abo-Modelle sind erstmal die Konsequenz. Neben der Bindung an Windows
> und dem Update-Zwang durch Rückwärts-Inkompatibilität natürlich.

Naja, wenn man etwas haben will, das outofthebox spielt und regelmässig 
gepflegt wird, landet man dann früher oder später doch bei Keil oder anderen. 
Z.B. Rowley Crossworks. Für MSP430 hab ich das eingesetzt, war sehr zufrieden 
(bin da vom gcc drauf umgestiegen und hatte dann endlich auch einen 
lauffähigen Debugger ;-). Sofern man den Prozessor nicht wechselt braucht man 
nicht zu updaten. Er hat auch einen schönen ARM-Compiler (IDE), hab den aber 
selber noch nicht ausprobiert.

M.
-- 

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

#226929 — Re: Lizenzen

Matthias Weingart <mwnews@pentax.boerde.de> schrieb:

> Marc Santhoff <m.santhoff@t-online.de>:
> 
> > Rafael Deliano <rafael_deliano@arcor.de> schrieb:
> > 
> >> > Die Bereitschaft seine Arbeit ohne Gegenleistung anderen zum
> >> > Geldver- dienen zu überlassen war früher wie heute begrenzt.
> >> 
> >> Das sehe ich auch so.
> >> Shareware war so ein Flop daß der Begriff inzwischen
> >> aus dem Vokalbular verschwunden ist.
> > 
> > Das klassische Kaufmodell hat sich aber auch irgendwie abgefressen.
> > Einmal kaufen und immer benutzen ernährt die Entwickler nicht.
> > Abo-Modelle sind erstmal die Konsequenz. Neben der Bindung an
> > Windows und dem Update-Zwang durch Rückwärts-Inkompatibilität
> > natürlich.
> 
> Naja, wenn man etwas haben will, das outofthebox spielt und
> regelmässig gepflegt wird, landet man dann früher oder später doch
> bei Keil oder anderen. Z.B. Rowley Crossworks. Für MSP430 hab ich das
> eingesetzt, war sehr zufrieden (bin da vom gcc drauf umgestiegen und
> hatte dann endlich auch einen lauffähigen Debugger ;-). Sofern man
> den Prozessor nicht wechselt braucht man nicht zu updaten. Er hat
> auch einen schönen ARM-Compiler (IDE), hab den aber selber noch nicht
> ausprobiert.

Für µC- bzw. SoC-Entwicklung ist das sicher so, mangels Alternativen.

Ich war gedanklich aber irgendwie in den Thread davor abgeglitten,
"Tool zum visualisieren von Daten (RS232) OpenSource". Daher die etwas
deplazierte Empfehlung...

Marc

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

#226876

On 2017-04-29, Rafael Deliano <rafael_deliano@arcor.de> wrote:
>> Ich habe keine Erfahrungen mit dem Board, aber es sollte eine
>> CMSIS-DAP-Firmware für das Debuginterface geben:
>>
>> https://mcuoneclipse.com/2013/05/17/cmsis-dap-with-iar-and-the-kl25z-freedom-board/
>> https://developer.mbed.org/handbook/Firmware-FRDM-KL25Z
>
> Es gibt das Original von P&E, verkrüppelt. Ich hab kein Problem
> wenn P&E seine kostenpflichtigen Produkte verkaufen will, aber
> dann sollten P&E oder Freescale explizit in der Dokumentation
> darauf hinweisen daß und wie die FRDM-Firmware künstlich
> "limitiert" wurde.
> Es gibt ein nachladbare Firmware von Segger ( non-commercial-use )
> und eine von Keil glaube ich ( non-commercial-use ) die jeweils
> wohl tut. Das non-commercial war da das Hindernis für mich:
> ich kann die FRDM-Boards letztlich nichtmal als Production-
> programmer verwenden. Da wird also dann noch ein kleiner Segger
> nötig.

Schade - ST macht bei ihrem ST-Link keine solchen Hampeleien.

>> Ich empfehle generell (für alle Cortex-XX) eine nackte
>> gcc/gdb/make/openocd-Toolchain, wer's braucht mit Eclipse (aber die normale,
>> nicht die von einem der Chiphersteller).  Das tut hier problemlos mit ST,
>> NXP, Atmel und TI-Chips.
>
> Wenn man viel Zeit in Konfiguration der Tools investiert, mag man so 
> glücklich werden. Aber der Ansatz scheidet für die meisten Firmen aus. 
> Keil/ARM wiederum ist so gesalzen teuer, daß die meisten kleineren
> Firmen damit auch nicht glücklich werden.

Wenn man nur schnell ein Produkt zusammenkloppen will, das dann keinen
Support braucht, kann man sicher mit einer kommerziellen IDE, die alles auf
Knopfdruck integriert, glücklich werden.

Wenn ich ein Produkt über Jahre pflegen will, nützt das wenig: dann muß ich
selber wissen, mit welchen Flags der Compiler aufgerufen wird, und die
eingebundenen Libraries verstehen, sonst knallt es beim nächsten Update und
ich weiss nicht, warum.  Ich will Makefiles, bei denen reproduzierbar
jedesmal das Gleiche herauskommt, und nicht eine IDE, wo das Detailwissen
sich hinter irgendwelchen Buttons versteckt, die beim nächsten Update ihr
Verhalten ändern.  Eclipse als Oberfläche ist dann OK (ich benutze aber
lieber Emacs).

Die Einstiegshürde ist höher, aber danach ist man deutlich flexibler.

Bei den fertigen Libraries der Chiphersteller (z.B. Bluetooth- und
USB-Stacke) gilt das Gleiche: am Start sind die ganz einfach und schön. Der
Teufel steckt dann im Detail, und man sucht ewig nach Fehlern, die dann in
dne Libraries stecken - die gesparte Einarbeitungszeit durch die
Plug&Play-Lösung wird dann beim Debuggen wieder aufgeholt.

cu
Michael

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

#226886

 > Schade - ST macht bei ihrem ST-Link keine solchen Hampeleien.

Die ARMs von ST habe nicht benutzt. Aber Kollegen verwenden
sie gerne und sie gelten auch als besonders preiswert.

MfG  JRD

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

#227319

In message <oe15fq$4q9$1@dont-email.me>
          Rafael Deliano <rafael_deliano@arcor.de> wrote:


> nötig.
> Es gibt natürlich irgendwo eine kostenloses, halbtotes "open source"
> Projekt der "community". Zero-support, debug it yourself, Jahre nach
> Ankündigung der kommerziellen Produkte verfügbar. Typisch "open source
> Lizenz" ( die dann für kommerzielle Anwendung Pferdefuß haben kann ),

http://usbdm.sourceforge.net/USBDM_V4.12/Freedom/html/index.html

finde ich bislang jetzt so zum Ausprobieren ganz funktionabel ;-)


-- 
mit freundlichen Gruessen/ best regards Joerg Niggemeyer Dipl.Physiker
WEB: http://www.nucon.de    http://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]

#226914

In message <odvnqf$2jl$1@dont-email.me>
          Rafael Deliano <rafael_deliano@arcor.de> wrote:

>> z.B. FRDM-KL25Z

>    Habe ich ca. 5 Stück in mehr oder weniger gefledertem Zustand
> rumliegen. Länger mit dem Teil Zeit verbracht als mir lieb
> ist.
Naja, wenn Du 5 Stück davon hast, dann kann dieses Board ja sooo 
uninteressant nicht gewesen sein.....

Eigentlich habe ich vor kurzem mit einem KEAZ-128 angefangen, weil
dieses Board kompatibel zu einem neuen Demoboard sein soll und ich bin 
bislang davon positiv überrascht.

KL25Z hatte ich mir auch zwei Stück einfach so dazu gekauft, weil mir 
die schön günstig schienen und Mbed kompatibel sind.

Gestern also zum Vergleich mal ein KL25Z in der NXP Umgebung
mit Helloworld Beispiel zum ersten mal zum Laufen gebracht und es ist 
im Vergleich zum KEAZ fuer mich schon erheblich schlechter, was die 
Übersichtlichkeit der libs angeht.

Das Updaten der Boardfirmware vom KL25Z stellte sich als nötig heraus, 
da sich zunächst der SDA Port nicht ansprechen liess. Bis man das 
rausfindet sind dann schon einige Minuten rum. Dann wollte sich die 
aktuelle Firmware nicht so leicht  direkt auf das Board raufladen, so 
dass hier ebenfalls ein paar Minuten rieselten.


> Also bin ich auf Keil übergegangen: leicht erlernbar,
> leicht bedienbar, funktiert gut. Aber wenn man über das
> kostenlose 32kByte Limit kommt wäre der extrem teuer.

Bislang finde ich, dass die NXP Umgebungen auch bedienbar sind.

Keil ist mir zum Probieren schon zu heikel, falls man über die Grenze 
kommt UND ich dann nicht ausweichen koennte, weil ich nix anderes 
kann..... Haben wollen natürlich gerne, allerdings eher wegen der 
Qualität z.B. des Compilers ;-)


>    Ich würde mir mal ansehen wie man einen Portpin auf einem
> Controller wie 68HC08 schaltet: Bit im DDR auf Output und dann
> Bit im Portregister schalten. Das sind zwei Assemblerbefehle.
>    Und dann sollte man sich ansehen wie das in C auf Cortex M0+
> aussieht. Faktor 10 mehr Gewürge.
> D.h. als Einstieg ungeeignet. 8 Bit ist da besser.

Mit der mbed Umgebung ist dies und ein Einstieg sehr leicht und mit 
dem KEAZ scheint mir das unter der NXP Umgebung auch nur unwesentlich 
schwieriger. Einzelne Reg-Bits direkt setzen, wie z.B. beim Pic, geht 
eben nicht. Also brauchts halt ein paar mehr Assemblerbefehle, hat 
aber nix mit 8bit zutun.






-- 

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

#226977

Hallo Jörg,


Joerg Niggemeyer <joerg.niggemeyer@nucon.de> wrote:

> Fuer den ersten mbed gibt es z.B. das Buch:
Danke für die Info! Auch zum Thema andere Starterboards. Habe mit dem
genannten bereits gearbeitet und fand alles soweit gut zu händeln. Mit
den späteren Anforderungen habe ich evtl. andere Bedürfnisse. ;-)

Ciao, Andreas 

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

#227001

Moin Andreas,
In message <1n5h12r.2ox5fa145bgd4N%sailcamvollmuell@gmx.de>
          sailcamvollmuell@gmx.de (Andreas Schmidt) wrote:
> Mit
> den späteren Anforderungen habe ich evtl. andere Bedürfnisse. ;-)

Natürlich ist das Hauptbedürfnis sich mit den eigenen Ideen
rumzuschlagen, und nicht hauptsächlich  mit den  Registersettings der 
unterschiedlichen MCUs, bis da was rauskommt, was man erreichen will.

Interessant vom Preis Leistungsverhältnis scheint fuer mich deswegen 
https://imagecraft.com
Hier will man das Registergeraffel einem vom Leibe halten - nettes
Versprechen ;-)
Läuft wohl mit dem bereits erwähnten Segger Tool - werde ich wohl
mal antesten - hat da schon mal jemand Erfahrungen mit gesammelt?

VG Joerg


-- 

[toc] | [prev] | [standalone]

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

csiph-web