Wundert mich, dass es hier rund um die Infineon ARM Controller XMC so
still geworden ist, obwohl sich sogar Infineon selbst hier mal vor
Monaten etwas versucht hat zu positionieren.
Aber egal, FYI:
Seit etwas über 2 Wochen gibt es nun für die ARM Cortex Controller-Reihe
XMC von Infineon die Entwicklungsumgebung DAVE4 in einer Beta-Version.
Neu ist, dass die "Apps" nun über eine XMCLib genannte Peripherielibrary
angesprochen werden können.
http://www.infineonforums.com/threads/2842-New-DAVE-version-4-available-as-Beta-Release
M.E. sind die Controller und das Konzept von DAVE wirklich fein. Zu
schade, dass bei Infineon scheinbar keiner Lust (oder Plan) hat, das mal
einem breiteren Markt (also auch dem der Hobbyisten, Bastler, Nerds)
zugänglich zu machen.
PS:
@Infineon: Zangs-Opt-In für Mailings zum Erhalt der Mail mit den
Downloaddaten stinkt². Was versprecht ihr euch überhaupt davon, da trägt
doch keiner, der noch seine sieben Sinne beisammen hat, seine Realdaten
ein, nur um mal in eine Betaversion reinschauen zu dürfen.
Olaf Mitender schrieb:> M.E. sind die Controller und das Konzept von DAVE wirklich fein.
Hmm..
Da bin ich ziemlich anderer Meinung.
Nachdem ich mir mal die Innereien dieser XMC Controller per Manual
angeschaut habe, kam mir das große Grausen. Ich hatte das schon mal hier
angesprochen.
- ab 0 kein Flash, sondern ROM - und zwar undokumentiert
- keine Möglichkeit, die Vektoren zu verlegen
- keinerlei Info, was mit den Interrupts tatsächlich passiert
- Flash geht an einer krummen Adresse los
- erster Flash-Sektor für irgendwelchen Krempel belegt
- eingebauter Bootlader nicht per Portpin selektierbar
Also, für mich ist es schon erstaunlich, wie sehr man mit so einer
kranken Chipgestaltung einen Cortex praktisch versauen kann. Als ich mir
das ein paarmal durchgelesen hatte und dann auch noch auf der Embedded
einen herzlich sachunkundigen "Fachmann" erleben mußte, war mir klar,
daß zumindest ICH mir diese Dinger nicht freiwillig antun werde. Da
stimmt mich auch der auf den Demoboards befindliche Spezial-Segger nicht
um.
W.S.
Wenn du bei Infineon nicht 5 oder 6stellige Stückzahlen abnimmst gibt es
von denen NULL Support.
Selten so einen arroganten Haufen Ahnungsloser gesehen.
Die sind bei uns ( kleineres Ing-Büro) schon seit Jahren rausgeflogen.
Nicht mal einen Transistor von denen würden wir einsetzen.
Im Moment setzen wir Microchip Pic18 , STM32 und einige Renesas ein.
Atmel AVR ist auch schon vor Jahren wegen deren Lieferschwierigkeiten
rausgeflogen.
Ich habe auch gerade das "Vergnügen", mich mit einem XMC4200
herumschlagen zu dürfen. Es ist schon faszinierend, was die alles an
peripherals da untergebracht haben und wie viele Einstellmöglichkeiten
es da gibt.
Leider ist das Reference Manual an vielen Stellen extrem schwach. Ohne
die XMC Peripheral Library habe ich nicht einmal eine einfache SPI
Schnittstelle zum laufen bekommen.
Die Dokumentation zur Peripheral Library ist dann wiederum auch
unvollständig und erklärt vieles im Bezug auf die Register. Es entsteht
also keine Abstraktion, sondern, man muss das Referenz Manual gelesen
haben, um die XMC Peripheral Library Dokumentation zu verstehen.
Welcher Hersteller ausser Infineon verlangt denn noch fuer ein
Standardprodukt wie einen Mikrokontroller ein "AGREEMENT ON THE USE OF
PRODUCT INFORMATION"?
Naja, eigentlich alle US-Firmen tun sowas ähnliches - aber lustlos und
nur weil es von ihnen verlangt wird - wegen der dortigen Gesetzeslage.
Und zu den Cortexen:
Jonathan schrieb:> Welchen Hersteller bevorzugst du denn lieber?
Lieber bevorzugen.. na OK.
Also, am liebsten sind mir solche Teile, wo de Chip einigermaßen
geradlinig und sauber konstruiert ist und wo die Doku gut, vollständig
und didaktisch sinnvoll geschrieben ist - und wo man die Chips auch als
kleinerer Anwender für nen passablen Obulus kriegt - und wo man mit ner
Standard-Toolchain in der Lage ist, die Chips zu programmieren OHNE sich
mit irgendwelchen grandiosen Dave's oder anderen Heinzen herumsielen zu
müssen.
Gerade bei Infineon scheint es mir, daß dieser Hersteller seine Chips so
grauenvoll entworfen hat, daß nicht einmal das Manual den Anwendern
wirklich hilft und daß eben genau DESHALB Infineon auf die beknackte
Idee gekommen ist, nicht etwa die Architektur gerade zu rücken, sondern
einen Workaround in Form eines Dave's zu erfinden, damit man das Zeugs
eventuell doch noch zu was gebrauchen kann.
Was ich speziell in der ARM/Cortex-Branche am ehesten (selber) mag ist
klar gesagt: NXP, dann ST und Nuvoton, dann Freescale, dann ne große
Pause...
W.S.
W.S. schrieb:> - ab 0 kein Flash, sondern ROM - und zwar undokumentiert> - keine Möglichkeit, die Vektoren zu verlegen> - keinerlei Info, was mit den Interrupts tatsächlich passiert> - Flash geht an einer krummen Adresse los> - erster Flash-Sektor für irgendwelchen Krempel belegt> - eingebauter Bootlader nicht per Portpin selektierbar
Wir haben unseren eigenen Bootloader für den XMC4x00 angepasst. Dieser
liegt am Anfang des Flashs und die Firmware dann dahinter; sie muss also
nach hinten gelinkt werden. Dazu verschiebt man an nur einer Stelle die
Anfangsadresse. Sämtliche Irq-Vektoren werden dabei "automatisch" in den
Firmware-Bereich verschoben. Schmerzfreier ging das bei noch keiner
anderen Architektur. Wobei ich gar nicht weiss, ob das nun ARM oder
Infineon zu verdanken ist. Ist auch egal, läuft wunderbar.
Den seltsamen Sektor mit dem komischen Krempel
(Boot-Tabellen-Dingsbums?) benutzen wir nicht - stört auch nicht weiter.
Im Prinzip geht's bei 0x0 los.
Der eingebaute Bootloader (BSL) ist per Portpin selektierbar und bietet
UART- und CAN-Kommmunikation. Nachteil: Er bietet kein Transmit-Enable,
wodurch RS485 nicht nutzbar ist.
Wir haben übrigens auf jeder HW, auf der der XMC4xxx drauf ist auch
einen FT234, der die USB-Kommunikation übernimmt. Sowohl der interne
Bootloader, als auch unser eigener laufen darüber problemlos. Letzterer
dann mit 921600 Baud...
Generell:
- Support langsam und träge
- Man muss DAVE benutzen, ansonsten wird man bekloppt. Wenn man das
macht, kann man die Annehmlichkeiten nutzen. Falls man ganz genau wissen
muss, wann was passiert (Timing, Irqs, etc), ist man mit der API
aufgeschmissen und nur nach Datenblatt bzw Manual will man mit dem Teil
wirklich nicht arbeiten! Dafür nehme ich dann bspw PIC24. Sehr
deterministisch (Interrupt-Latenz usw) und man kann bspw eine UART mit
fünf Zeilen konfigurieren. Beim XMC undenkbar...
- DAVE3 war, was die komplizierten Module (ADC, Trigger-Signale) angeht,
ziemlicher Mist. Das hat sich mit DAVE4 wesentlich verbessert. Es gibt
noch relativ wenige Code-Beispiele, welche leider auch nicht so
wahnsinnig hilfreich sind.
- DAVE gibt es nur für Windoof. Dagegen finde ich die Tools bei
Microchip sehr geil: Den XC16-Compiler benutze ich dann meist unter
Linux in einer Make-Umgebung.
- Der XMC4 ist eine eierlegende Wollmilchsau. Man kann wirklich fast
JEDEN Scheiss einstellen: Flankensteilheit der GPIOs,
Pullup/-down-/-links/-rechts ;-) ADC-Strategie (Auftrags-Queues,
Background-Scan), CRC-Engine, UART mit beliebiger Wortlänge (1..63 bit),
Ethernet, USB, blablabla...
Ist schon geil, aber wehe wenn's mal nicht funktioniert. Man rührt dann
doch wieder in den Eingeweiden rum, um zu verstehen, woran es hängt.
Kein Spass.
Das Manual hat übrigens über 2600 Seiten. Das liest man nicht mal eben
durch...
Für Hobbyisten oder Kontrollfreaks nicht geeignet!
Aber man kriegt mit DAVE4 wirklich in Minuten einen Cortex zum Laufen
(blinking led). Ist auch was wert...
e-bert schrieb:> - DAVE gibt es nur für Windoof.
Da hatte ich mich auch gefragt, was das für einen Sinn macht, ein in
Java geschriebenes Tool nur für Windows anzubieten.
