Hi, Bin kürzlich über diese "neue" ARM uC-Familie STM32 gestolpert: http://mcu.st.com/mcu/inchtml.php?fdir=pages&fnam=stm32 Die Features scheinen recht interessant. Weiß jemand, wann die wirklich erhältlich sein werden, bzw. ob es die schon gibt? - 2 x 12 Bit ADC (jeweils 8 mal multiplexed) - eine Menge Timer (inkl. PWM), USB, CAN, USART, I2C, SPI, uvm. (natürlich sind die Pins maximal ungünstig mehrfach belegt ;) - bis zu 20K RAM - bis zu 128K Flash - kleiner Footprint (LQFP48,LQFP64,LQFP100) Wäre eine interessante Alternative zu uCs der LPC2000-Serie (die ich im letzten Projekt benutzt habe). Leider ist RAM im vgl. etwas klein, aber die 12 Bit ADC und sonstigen Features sind interessant, oder übersehe ich da was? Die einzigen ARM-Cores mit 12_Bit ADC, die ich sonst noch kenne sind von Analog Devices (bei denen das RAM leider wirklich sehr sehr begrenzt ist) und einige aus der STR7-Serie (aber nur 4-Kanal). Grüße, Andreas
Soweit ich weiss gab es vor 1-2 Monaten schon boards von Keil. dann war ploetzlich so etwas wie EMbargo drauf, vielleicht baer auch nur fuer Mitbewerber, kann ich nicht mit Sicherheit sagen. Die Chips sind eine komplette Neuentwicklung und werden bestimmt mal recht gut sein. Ab sie es schon sind kann ich nicht beurteilen, denn wir haben keine Chips in die Haenden bekommen als wir es versuchten vor ca 6 Wochen. Robert
Mittlerwerweile gibt es das Keil MCBSTM23, mit STM32F103 drauf. Ich kämpf mich gerade - ohne Driverlib - durchs Datenblatt. Ist - finde ich - erst mal recht verwirrend, besonders wenn man die schönen AVR Datenblätter gewohnt ist ;-) Greetz, /th.
STM hat jetzt ein richtig preiswertes und auch "lustiges" Dev-Tool im Angebot. Siehe: http://www.st.com/mcu/contentid-105-110-STM3210B_PRIMER.html
Joah, das kleine Ding ist echt lustig. Sitzt ein STM32 und ein 3D-Beschlleunigungssensor drauf. Auf einem Farbdisplay ein schöner PacMan Clone ;-) Mittlerweile bin ich durch einen Teil der Standardperipherials durch. Wenn man das Prinzip - das sich zu anderen etwas unterscheidet - erst mal raushat, fängt der Controller an, richtig spass zu machen. Und es ist mir bisher noch nciht gelungen, mich da auszusperren grins Lt. Auskunft von ST haben die das Debug-Modul vom Core entkoppelt. Wenn mich nicht alles täuscht, könnnte ich damit sogar nen Fehler bei der ClockTree-Programmierung wieder wettmachen, was bei einem anderen zur völligen Unbrauchbarbeit des Chips führen kann. Weiterhin ist zu sagen, dass die Peripherials auch mit Registern gemessen an der Komplexität des Controllers einfach zu programmieren sind (ich bin kein DriverLib-Fan, mag das lieber selber machen ;-) ). Greetz, /th.
Hallo Thorsten, freut mich, dass Du inzwischen mit unserem neuling Spass hast. Du hattest die Keil Board vor dem Produkt-Launch erhalten, wie üblich das heisst alles war noch nicht 100% fertig. Library ist jetzt einfach vom Web zu herunteladen, genau so wie eine ganze reihe von Docs und SW (AN, USB Dev-Kit, Flash-Loader, und noch mehr), einfach unter folgenge Link schauen: http://www.st.com/mcu/familiesdocs-110.html Bin interessiert besser zu verstehen deine Vergleich AVR vs STM32 Docs, und was wir verbessern könnten. Am bestens wir telefonieren darüber. Zu Andreas Frage, ob die Teile schon gibt, kann ich es bestätigen. Die meisten Distributor haben den STM32 seit ein paar Woche aufs Lager. Mehr RAM ist wird bei der nächsten Welle von STM32 Derivate geben (Plannung ist Sampling Q2'08, Volume-Produktion mitte 2008). Übrigens, der Hitex STM32-Stick ist auch jetzt verfügbar: http://www.st.com/mcu/contentid-107-110-STM3210B_PFSTICK.html Grüss, T.E.
"Mehr RAM ist wird bei der nächsten Welle von STM32 Derivate geben (Plannung ist Sampling Q2'08, Volume-Produktion mitte 2008)." Hast Du da nähere Infos zu? Sprich: wieviel RAM und kommen auch höhere Taktfrequenzen?
Hi, @T.E.: was ich so auf die Schnelle auf der ST-Seite nicht herausbekommen konnte: Compiler etc. Gnu-C/C++ geht offensichtlich. Und damit wohl auch unter Linux. Aber wie sieht es mit Tools/Lösungen - was Flashen und Debuggen betrifft - unter Linux aus? Für mich wäre das zumindest ein NoGo, wenn ich nach dem Compilieren/Linken unter Linux nicht mehr weiter komme! Wobei es der Verbreitung dann auch nicht schlecht tun würde, wenn diese Tools nicht propritär von einer Firma zum Preis von x Kilo-Euro verfügbar wären. Für OpenSource würde das z.B. heißen, die entsprechenden Spezifikationen verfügbar zu machen! Schönen Tag noch, Thomas
@ T. E. Leidet das Ding dann auch unter den typischen Hitex-Macken? (vgl. STR9-ComStick) * Schaltungsunterlagen nur teilweise offengelegt * kein Standalone-Betrieb möglich (d.h. nur in Verbindung mit einem PC nutzbar)
btw: Ich werde mich demnächst an einen "Hack" des STR9-Comstick setzen :-) Ich denke, die USB unabhängigkeit für die Spannungsversorgung sollte recht einfach funktionieren (schliesslich kocht Hitex ja auch nur mit Wasser), und um ein normales JTAG interface anzubringen werde ich die Beinchen etwas anlupfen und mich an die Schaltungsvorgaben von Keil halten. Dann ist das Dingens auch mit ULINK bzw. IAR oder einem beliebigen Wiggler programmierbar. Ich arbeite halt (sehr gerne) mit den Keil Tools und möchte da auch bei bleiben (der Mensch ist ein Gewohnheitstier :-) ) Nur die Zeit ... könnte mal etwas mehr (frei) davon gebrauchen grins VG, /th. Ein wenig Input zum STM für die Selbermacher:
1 | #define GPIO_CONF_BIT(BIT) ((BIT>7? BIT-8 : BIT) << 2) // 4Bits per port pin
|
2 | |
3 | // Mode and Conf Bits
|
4 | #define MODE0 0
|
5 | #define MODE1 1
|
6 | #define CONF0 2
|
7 | #define CONF1 3
|
8 | |
9 | |
10 | // Port Mode/Conf
|
11 | #define GPIO_MODE_SPEED2MHZ ((1<<MODE0) | (1<<MODE1)) // lower 2Bits are speed (in output mode)
|
12 | #define GPIO_MODE_PUSH_PULL ((0<<CONF0) | (0<<CONF1)) // higher 2Bits are pin configuration
|
13 | |
14 | |
15 | ...
|
16 | GPIOB->CRH = ((GPIO_MODE_PUSH_PULL | GPIO_MODE_SPEED2MHZ) << GPIO_CONF_BIT(10)) | ..... |
...oder einfach bit_on/off 4 mal für die Mode/conf-bits, jeweils mit shift GPIO_CONF_BIT(PINx). Mit 4x bit_on/off untereinander und den mode/conf-bits kann man die konfiguration so aus dem Datenblatt Sektion GPIO eintragen. Ganz einfach! Auch die andere HW wie UART, ADC, TIMER liessen sich problemlos und recht simpel aufsetzen. --- Verwirrend ist nur erst mal die GPIO-Konfiguration, denn die ist ganz anders als man das gewohnt ist. Hier sind PORT_DDR, PORT_AFSEL, PORT_PULLUP/DOWN usw. in zwei Register pro Port verpackt, jeder der 16Pins eines GPIO bekommt 4Bits (2Mode, 2Conf) zum Einstellen. Zu Anfang war ich darüber am schimpfen, was das denn solle. Dann bekam ich aber die Info, dass es beim einzelnen Umschalten der Config zu Glitches kommen kann, was vermieden wird, wenn die ganze Conf. in einem Rutsch gesetzt wird. Macht Sinn, ist aber gewöhnungsbedürftig. @T.E.: Das mit dem Vergleich der Datasheets AVR/STM32 muss ich mir mal genau ansehen. Die Sache ist die, dass ich im Grunde mit dem AVR das "Controller-Laufen" gelernt habe, und das auch grösstenteils ohne fremde Hilfe. AVR ist auch um einiges einfacher, da macht man DDRA = 0xff; PORTA = 0x55; und schon sind ein paar Lämpchen an :-) D.h. beim AVR schlage ich Seite UART auf, programmiere die Register ein mal von oben nach unten runter und dat dingen rennt! Die ARM-basierten Controller sind da etwas komplizierter. Man kann nicht einfach das Datenblatt oder Manual aufschlagen und den UART runterproggen, sondern braucht erst mal ein wenig Grundwissen zu - Aufsetzen des Clock Tree, PLL - Clock Gating - ev. anderes (z.B. Write Masks für GPIO) Bis man das alles raushat (from Scratch) ist die Fluch-Kasse schon ganz gut gefüllt. Ich kann mir nciht anmaßen, über das Vorwissen anderer zu Urteilen. Interessant wäre aber doch ein Kapitel im Manual oder ein "Getting started", in welchem die Fallstricke erläutert werden, in die man beim Umstieg von einem 8Bitter auf einen (gegebenen) ARM-basierten controller fallen kann. Zum Beispiel könnte da kurz erklärt werden, was die PLL da auf dem Dingen soll, warum die LED am GPIO nicht angeht, wenn man vergisst, die Clocks anzuschalten (also die Möglichkeiten der Energieeinsparung) etc. Sehr schön gelöst bei Keil, hier wird eine Startup.s mitgeliefert, in welcher man für den STM32 das Clock-Setup machen kann. Hat mir sehr geholfen, denn ich habe erst die Periperals programmiert und dann Step by Step die Clock-Gatings im Startup abgestellt und in meine Software übernommen. Also Fazit 8Bit->ARM basierte: Man muss sich erst mal an verschiedenen Stellen des Manual einlesen, bevor man versucht, ein Lämpchen einzuschalten. Wenn man das etwas vereinfachen könnte, würden - denke ich - viel Zeit und Flüche gespart. VG, /th.
@tom: Vorab: habe kein Board mit STM32 aber ein wenig mit Luminary Stellaris Controllern herumgespielt (gleicher Core). Der zur Zeit aktuelle offizielle GNU compiler V4.2.x unterstützt C-M3 noch nicht, das wird wohl mit Version 4.3.0 kommen. Eine vorkompilierte GNU Cross-Toolchain mit Anpassungen für C-M3-"targets" ist auch für Linux-"hosts" bei Codesourcery erhältlich. Die "Lite" Version ist kostenlos. Support für STM32 wurde vor einiger Zeit von Spencer Oliver in OpenOCD integriert. OpenOCD ist "Multiplattform" und auch für Linux compilierbar. Lt. Dokumentation kann man damit STM32 Controller Flashen. OpenOCD bietet auch einen GDB-server. Ob OpenOCD jedoch mit dem Hitex-Stick der dem "Ufo" funktioniert, kann ich nicht sagen. Falls die integrierten Debug-Interfaces auf FTDIs FT2232 basieren, sind die Chancen für OpenOCD aber gut. Ansonsten wie von Throsten De buhr erwähnt die JTAG-pins des Controllers irgendwie herausführen und FT2232-"Probe"/Wiggler mit OpenOCD verwenden. Martin Thomas
Hallo, nach der Erfahrung mit dem STR9-comStick, der sehr oft nicht nur als Evaluierungstool sondern auch für kleine Projekte eingesetzt wird, hat Hitex den STM32-PerformanceStick anders konzipiert. Erstens ist auf dem Erweiterungsstecker fast alles herausgeführt, was der STM32 im 64 pin Gehäuse zu bieten hat und ausserdem ist er auch stand alone von hinten zu powern (möglichst nicht, wenn er am PC steckt!). Bei den Erweiterungsboards sind hierfür sogar Anschlüsse vorgesehen. Dass bei dem Schaltplan nur der controllerspezifische Teil veröffentlicht ist, sollte eigentlich verständlich sein. Der Stick soll ja als Referenz für STM32 Designs dienen und nicht als Referenz für JTAG Debugger :-) Gruss Kurt
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.