Announcement: there is an English version of this forum on 
Hallo, ist jetzt keine Frage oder so, läuft ja alles :-) Nur mal als Basteltip für die Cortex Fraktion, die nicht gleich die Multimedia Boliden einsetzen will. Dieses Miniboard mit 128kb (Chip getauscht) und 20kb RAm ist einfach genial, selbst Grafik ist kein Thema und die zu wenigen I/O kann man durch Verwendung con 74HCT595 bei fast 36 Mhz Clock Rate im Schieberegister einfach aufblasen. Bisschen tricky ist die Deaktivierung der Default JTAG Debug Pins, da sonst 3 Pins nicht verwendbar wären. Ich debugge über swd auf 2 Leitungen. Nunmehr die Basisroutinen der Grafik Lib fertig, SPI spielt mit 12 Mhz trotz Lochraster dazu die ILI9341 Lib von Ardafruit Aduino auf STM32 umgeschrieben, einiges rausgeworfen, anderes dazu gebracht. Funkmodul läuft bestens. Ist auch durch ein EEPROM als "Funkdatenspeicher" für die Basisstation gedacht, die ein Backup ihrer gesammten Daten da ablegt. Und der ganze Ramsch sind nicht mal 20kb kompiliert, trotz float und printf. Programmiert werden sie mit einem 5 Euro China Klon ST-Link V2 in USB Stick Format. Kann ich absolut nur empfehlen, megageile Maschinchen mit 72 Mhz (bei 50mA) und 32 Bit Power! Leider jedoch sind die Boards gegen EMV empfindlich, habe schon einige tote Pins wieder auf einem, Anfassen und rumtragen mögen sie nicht. Gruss, Christian
Angehängte Dateien:
-
CAM01193.jpg
240 KB -
CAM01194.jpg
230 KB
Angehängte Dateien:
watten dat denn schrieb: > Schöne weiße Lochraster. Passt gut zur Tasse. :-* Jo, die gehen hier "in Serie" :-) Ist ein NRF24L01+.
Christian J. schrieb: > Dieses Miniboard mit 128kb (Chip getauscht) das kann man sich evtl. sparen weil nach einigen Berichten im Netz der F103C8 entgegen dem Datenblatt auch 128 kB Flash haben soll. Ich habe versucht das mit dem ST-Link Utility anzusprechen, aber das liest die Device ID aus und blockiert den Zugriff auf >64k. Nur beim Erase kann man Blöcke über der 64k Grenze löschen aber das hilft natürlich auch nicht. Mit dem Atollic TS habe ich ein Projekt für den F103CB gemacht und ein grosses Array eingebaut. Das wird aber auch nicht korrekt geschrieben mit GDB/ST-Link. Die zeigen zwar keine Fehlermeldungen, das Array im Niemandsland bringt aber den Debugger durcheinander. Kennt jemand noch einen Trick den 'versteckten' Speicher zu nutzen?
Was passiert, wenn Du nen USB Bootloader hochlädst, und dann die Software über die Arduino IDE hochlädst?
das Arduino Zeug für STM32 habe ich nicht installiert. Ich habe aber mal das Flashsize Register ausgelesen und das meldet mir auch 64 kB.
1 | #define FLASH_SIZE_REG 0x1FFFF7E0
|
2 | int getFlashEnd(void) |
3 | {
|
4 | unsigned short *flashSize = (unsigned short *) (FLASH_SIZE_REG);// Address register |
5 | return ((int)(*flashSize & 0xffff) * 1024) + 0x08000000; |
6 | }
|
so wird im STM32duino bootloader die flashsize ermittelt. Dann gibt es möglicherweise doch C8 die nur 64k haben, eine Garantie hat man bei solchen Hacks natürlich nicht. noch ein Link zu dem Thema: http://www.eevblog.com/forum/microcontrollers/ebay-stm32f103c8-board-reports-more-memory-than-it-should/
The trick is to tell OOCD that there are 2 banks of 64K And not let it probe the chip, witch only returns one bank diff -Naur stm32f1x.cfg stm32f1x_128.cfg --- stm32f1x.cfg 2014-08-22 17:46:29.954188309 +0200 +++ stm32f1x_128.cfg 2015-09-16 21:42:38.117258883 +0200 @@ -80,7 +80,10 @@ # flash size will be probed set _FLASHNAME $_CHIPNAME.flash -flash bank $_FLASHNAME stm32f1x 0x08000000 0 0 0 $_TARGETNAME +#flash bank $_FLASHNAME stm32f1x 0 0x20000 0 0 $_TARGETNAME +flash bank $_FLASHNAME stm32f1x 0x08000000 0x20000 0 0 $_TARGETNAME +#flash bank $_FLASHNAME stm32f1x 0x08000000 0 0 0 $_TARGETNAME +#flash bank $_FLASHNAME stm32f1x 0x08080000 0 0 0 $_TARGETNAME /Bingo
:
Bearbeitet durch User
Karsten F. schrieb: > The trick is to tell OOCD that there are 2 banks of 64K > And not let it probe the chip, witch only returns one bank thanks Karsten. until now I used Atollic TS with the built-in ST-Link debugserver. I was able to install OCD and configure TS to use it with my ST-Link V2 probe. For the configuration I used:
1 | -f interface/stlink-v2.cfg -f board/stm3210b_eval.cfg |
for my testapp with <64k this works fine, but my app with a large array I get the size error:
1 | Info : device id = 0x20036410 |
2 | Info : flash size = 64kbytes |
3 | Error: Memory write failure! |
now I'm not sure how to use your commands. Is OCD already using the probing stuff or do I have to add it to the debug script?
Karsten F. schrieb: > /Bingo ok, got it! great stuff, it works! thanks again! voll krass, Speicher verdoppelt ohne Lötkolben :-) es war einfach, in der stm32f1x.cfg die Zeile
1 | flash bank $_FLASHNAME stm32f1x 0x08000000 0x20000 0 0 $_TARGETNAME |
nach
1 | # flash size will be probed |
austauschen. noch eine Idee: damit müsste man aus ST-Link V2 auch einen V2.1 machen können?
Boah, das ist doch Nonsense! Die Chipse kosten 6 Euro und ich brauche mit Profi-Equipment grad mal 5 Minuten pro Board die zu tauschen inkl. Reinigung vom Fluxer. Es ist doch bekannt, dass defekte Chips runter gelabelt werden, das war doch schon beim 386 SX Prozessor mit defektem CoPro so. Ok, aber basteln macht Spass ....
Christian J. schrieb: > Es ist doch bekannt, dass defekte Chips runter > gelabelt werden, Mit anderen Worten: Die oberen 64k sind defekt?
Torsten C. schrieb: > Christian J. schrieb: >> Es ist doch bekannt, dass defekte Chips runter >> gelabelt werden, > > Mit anderen Worten: Die oberen 64k sind defekt? Ich habe bis 2002 bei einer Chipschmiede gearbeitet und da war es so. Defekte Speicherregionen wurden "ausgebittet" nachdem die Chip im Tester waren, damals war aber Flash noch was Neues.
Torsten C. schrieb: > Mit anderen Worten: Die oberen 64k sind defekt? Kann sein - muss nicht. Darfst Dich aber dann eben gerne auf die vermutung verlassen :) rgds
Christian J. schrieb: > das war doch schon beim 386 SX Prozessor mit defektem > CoPro so. Das war der 486er und der spielte preislich in einer ganz anderen Liga. Da hat sich das gelohnt, teilweise defekte Chips zu recyclen. Bei einem Chip, dessen Herstellung um 1€ liegen dürfte, lohnt sich sowas nicht. Da wäre der Aufwand viel zu groß und zu teuer. Da ist einfach überall das gleiche Silizium verbaut. Ich hab gestern mal probiert, der STM32F030F4P6 lacht einen auch mit 32kB Flash an. Und bei dem wird bestimmt nix selektiert. Torsten C. schrieb: > Mit anderen Worten: Die oberen 64k sind defekt? Vielleicht nur nicht getestet, oder hält nicht alle Spezifikationen ein. Einmal vollschreiben mit verify und dann bei Zimmertemperatur betreiben, sollte das Risiko in Grenzen halten. Für kommerzielle Produkte aber nicht zu empfehlen.
Hallo Christian, mir hat die Woche auch der Postbote einen St-link V2 und so ein Board mit einem STM32F103C8T6 gekauft. (Ich frage mich ja, warum man sich mit AVR und Dragon rumschlägt, um Onchip-debugging zu bekommen und hier gibts das einfach so und in günstig.) Welche Software/Bibliothek verwendest du? Ich auf dem Board erfolgreich den LED-Blink-Test mit libopencm3 zum Laufen bekommen, bin mir aber nicht, ob man das verwenden will: http://www.libopencm3.org/wiki/Main_Page
bernd schrieb: > Welche Software/Bibliothek verwendest du? Die EmBitz IDE und PeriphLib von ST. Spielt alles zusammen out of the box. Jo, keine Ahnung wieso man sich mit AVR rumschlägt, Käfer fahren wenn man einen Porsche haben kann.
bernd schrieb: > Hallo Christian, > > mir hat die Woche auch der Postbote einen St-link V2 und so ein Board > mit einem STM32F103C8T6 gekauft. (Ich frage mich ja, warum man sich mit > AVR und Dragon rumschlägt, um Onchip-debugging zu bekommen und hier > gibts das einfach so und in günstig.) > > Welche Software/Bibliothek verwendest du? Ich habe mir diese libopencm3 mal angeschaut ..... also was bringt das jetzt genau? Ich meine die StdPeriphLib erschlägt doch sowieso schon alles? Man bleibt kompatibel zu Code, den man aus dem Netz her kopiert oder Beispielen. Ich habe diesen DIP40 Käfer jetzt mal in meinem Demo projekt einfach ausgereizt, einfach alles verwendet, was Sinn macht (oder auch nicht). Da kommen Funkdaten rein, da laufen x Timer, die RTC auch noch dabei, ADC sampelt über DMA, da wird ein Grafikdisplay ständig bedient usw. Und die CPU ist immer noch nicht "fertig", da geht noch was an Auslastung. Und trotz Lib Einbindung grad mal 30kb voll. Habe heute die Kiste AVR Chips und Arduino Micros die hier noch rumlagen in die Bucht eingestellt. Kinder-Spielzeug gegen 32 Bit Power mit eine Unmenge mehr an Möglichkeiten als diese 8 Bit Zwerge...
Christian J. schrieb: > Ich habe mir diese libopencm3 mal angeschaut ..... also was bringt das > jetzt genau? Ich meine die StdPeriphLib erschlägt doch sowieso schon > alles? libopencm3 ist eine Alternative zur ST Standard-Peripherie-Lib. Allerdings ist sie im Gegensatz zu letzterer nicht auf µC von ST beschränkt. Und sie ist von Anfang an auf eine freie Toolchain ausgerichtet. > Man bleibt kompatibel zu Code, den man aus dem Netz her kopiert > oder Beispielen. Es gibt natürlich auch zu libopencm3 jede Menge Baispiele. Und einige Projekte im Web verwenden sie auch (z.B. Blackmagicprobe). Ist am Ende eine Abwägung, ob man lieber eine freie Standardlib verwendet, die man für verschiedene Cortex-M verwenden kann. Oder ob man sich an die halb-kommerzielle Standardlib eines einzelnen Herstellers binden will die auch nur für die Cortex-M dieses einen Herstellers funktioniert.
Christian J. schrieb: > Habe heute die Kiste AVR Chips und Arduino Micros die hier noch rumlagen > in die Bucht eingestellt. Kinder-Spielzeug gegen 32 Bit Power mit eine > Unmenge mehr an Möglichkeiten als diese 8 Bit Zwerge... Dieses "höher, schneller, weiter" Denken ist Unsinn. Es gibt genug Projekte, wo die Rechenleistung eines 8-Bitters bei weitem ausreicht. Und wo andere Vorzüge der 8-Bitter zum tragen kommen: - trotz des Preisverfalls der ARMs immer noch preiswerter - potenziell kleinere Gehäuse ohne auf QFN oder BGA gehen zu müssen - höhere Codedichte - einfacher zu erlernen bzw. zu verstehen - besser vorhersagbares Zeitverhalten - potentiell geringerere Leistungsaufnahme
Axel S. schrieb: > - höhere Codedichte Da gibt es irgendwo auf der ARM Website einen Vergleich der zeigt, dass ARM Thumb Code tatsächlich eine höhere Dichte als 8051 Code hat aufgrund der cleveren Kodierung. Axel S. schrieb: > - besser vorhersagbares Zeitverhalten In Bezug auf einzelne Instruktionen ist das richtig (Pipeline), aber aufgrund geringerer Interrupt Latenzen, allgemein höherer Frequenz, und (bei STM32) mächtiger Timer Funktionen zur Verschaltung untereinander und mit ADC usw. lässt sich mit ARM auch sehr gut Echtzeit umsetzen. > - potentiell geringerere Leistungsaufnahme Ein EFM32 zB verbraucht weniger als der sparsamste AVR, und ist auch noch schneller mit den Rechnungen fertig bevor er wieder schlafen geht. Ist also alles pauschal nicht so klar zu sagen :-P
@TO Du hast hier schon mal was mit einer weißen Platine (glaub ich) vorgestellt und ich hielt das zunächst für Lochraster (auf dem Handy gelesen). Vielen Dank für diese schöne Idee! Kann ja auch bunt sein. Werde ich für mich im Hinterkopf behalten.
> Ein EFM32 zB verbraucht weniger als der sparsamste AVR, und ist auch > noch schneller mit den Rechnungen fertig bevor er wieder schlafen geht. Kannst du eine konkrete Schaltung/Anwendung zeigen, an der man deine Aussage überprüfen kann. Insbesondere interessiert mich der Verbrauch, der "sparsamer" als der eines AVR-Controllers sein soll.
Bernd schrieb: > Insbesondere interessiert mich der Verbrauch, der "sparsamer" als der > eines AVR-Controllers sein soll. Ich hatte einfach irgendwann mal im Datenblatt den Stromverbrauch pro MHz verglichen. Ich kann aber gerade nicht nachsehen welche Controller das jetzt genau waren...
Axel S. schrieb: > Dieses "höher, schneller, weiter" Denken ist Unsinn. Es gibt genug > Projekte, wo die Rechenleistung eines 8-Bitters bei weitem ausreicht. Da stimme ich zu. > Und wo andere Vorzüge der 8-Bitter zum tragen kommen: > > - trotz des Preisverfalls der ARMs immer noch preiswerter Das würde ich so generell nicht sagen. Such mal z.B. nach AVRs die im 1000er-Preis günstiger als der STM32F030F4 sind. Selbst bei den Attinys gibt es nur ganz wenige bei denen das der Fall ist. Einen Punkt hast Du in Deiner Liste noch vergessen: - die meisten 8bitter können direkt 5V push-pull treiben
Hast den auch schon übertaktet? Beim c8 sollen ja 128 MHz gehen? Was mich noch interessiert ist der AX Wandler. Ob der beim übertakten auch noch bischen mehr leisten kann. Ich find die AVRs für 5 V Sachen gut.
Dr. Sommer schrieb: > Bernd schrieb: >> Insbesondere interessiert mich der Verbrauch, der "sparsamer" als der >> eines AVR-Controllers sein soll. > > Ich hatte einfach irgendwann mal im Datenblatt den Stromverbrauch pro > MHz verglichen. Ich kann aber gerade nicht nachsehen welche Controller > das jetzt genau waren... Also nur eine Bauchmeinung ohne Aussagekraft.
Bernd schrieb: > Also nur eine Bauchmeinung ohne Aussagekraft. Wenn ein Datenblatt für dich eine Bauchmeinung ist, was hat dann für dich Aussagekraft? Ein Experiment das ich unter Laborbedingungen zusammenschustere? Warum ist es eigentlich so schwer zu glauben, dass ein ARM Prozessorkern, an dem ARM und assoziierte Firmen seit Jahren herumoptimieren (auch fertigungstechnisch), besser sein kann als der AVR, der seit ewigen Zeiten unverändert produziert wird?
Dr. Sommer schrieb: > Warum ist es eigentlich so schwer zu glauben, dass ein ARM > Prozessorkern, an dem ARM und assoziierte Firmen seit Jahren > herumoptimieren (auch fertigungstechnisch), besser sein kann als der > AVR, der seit ewigen Zeiten unverändert produziert wird? Nu mal keine Glaubenskriege´hier, ok? Ich war in Firmen tätig, wo viel AVR verbaut wird und viel PIC und auch wo nur ARM, MSP etc. Sind alle da, machen kulturelle Vielfalt aus :-) Mir gehts nur um Basteln, ich bin schon lange kein Entwickler mehr. Für den Temp. Sensor in der Butterdoese draußen war ein nackter Attiny84 die beste Wahl, bespielt mit der Arduino IDE, für die Basisation war es ein 407 M4 und für das Display hier, was durch die Basis mit Daten gefüttert wird ist der 103C8 optimooooal. Nachteil: Um das Gleiche zu erreichen wie mit einem AVR sind erheblich mehr Codezeilen nötig, Textzeilen, nicht Code. Weil der eben eine erheblich komplexere Peripherie hat, die auch deutlich schwerer zu verstehen ist als die vom AVR. Das Display spielt auf dem Lochraster mit 16 Mhz bei ca 4cm langen Leitungen. Hat eine sehr gute Performance bei schnellen Grafikwechseln. Das kann nur ein ARM leisten. Die Mini Board habe ich jetzt für 3,65 / Stück bei aliexpresss bestellt, billiger gehts nicht mehr. Einfach TOP!
Andreas R. schrieb: > Hast den auch schon übertaktet? Beim c8 sollen ja 128 MHz gehen? Nö. Dann werden sie sicher instabil. Der frisst bei 72 Mhz und 2 x 36 Mhz Bussen bei mir derzeit 55mA. Das soll auch genug sein.
Wenn man AVR und Arduino IDE als eine Seite des Vergleiches nimmt, sollte man bei ARM auch etwas vergleichbares heranziehen. Das wäre z.B. mbed mit Online-IDE oder offline Toolchains. In beiden Fällen benötigt man eine Code Zeile, um einen Pin als Ausgang zu konfigurieren und eine zweite Code Zeile um ihn auf high/low zu setzen. Wenn man auf der ARM Seite die Programmierung über die Hersteller HALs nimmt, sollte man natürlich auf AVR Seite auch eine vergleichbare Abstraktionsebene verwenden. In diesem Fall wären es beim AVR aber tatsächlich weniger Code Zeilen.
Dr. Sommer schrieb: > Bernd schrieb: >> Also nur eine Bauchmeinung ohne Aussagekraft. > > Wenn ein Datenblatt für dich eine Bauchmeinung ist, was hat dann für > dich Aussagekraft? Ein Experiment das ich unter Laborbedingungen > zusammenschustere? > Warum ist es eigentlich so schwer zu glauben, Ich will nicht glauben, ich will wissen. aber sass man gut sein. Du gehörst zu denen hier, die einfach eine Meinung raus hauen ohne dieser näher zu belegen. ETX.
Instabil? Nicht gut! =(:oO) Hier steht was von 225 MHz, die noch gehen sollen. http://blog.tkjelectronics.dk/2010/02/stm32-overclocking/
Axel S. schrieb: > - besser vorhersagbares Zeitverhalten Lies mal bitte Datenblätter. Gerade bei der wichtigen Interruptlatenz ist man beim AVR ja von Mondphasen und Ähnlichem abhängig. Das ist beim Cortex deutlich besser. Christian J. schrieb: > bernd schrieb: >> Welche Software/Bibliothek verwendest du? > > Die EmBitz IDE und PeriphLib von ST. Spielt alles zusammen out of the > box. > Jo, keine Ahnung wieso man sich mit AVR rumschlägt, Käfer fahren wenn > man einen Porsche haben kann. Lustig. Porsche haben und dann Fiat-Schrott (sprich: lausige Libraries) dranschrauben. Wozu diese unsägliche Library? Der M3/M4 ist doch nun wahrlich nicht schwer. Erst recht der STM32F103, der ja ein besonders triviales Exemplar der STM32-Familie ist. Wozu also dies Bloatware?
Dr. Sommer schrieb: > Bernd schrieb: >> Insbesondere interessiert mich der Verbrauch, der "sparsamer" als der >> eines AVR-Controllers sein soll. > > Ich hatte einfach irgendwann mal im Datenblatt den Stromverbrauch pro > MHz verglichen. Ich kann aber gerade nicht nachsehen welche Controller > das jetzt genau waren... Gerade in µC Anwendungen und besonders in Anwendungen wo ein 8-Bitter genug Rechenleistung hat, ist der Verbrauch pro MHz nur selten das Argument. Da geht es dann eher darum, wie groß der Verbrauch im Sleep ist. Und ob es geeignete Methoden gibt um wieder aufzuwachen. Und falls das nicht klar gewesen sein sollte: mir geht es nicht darum, daß jemand jetzt noch neu auf 8-Bitter setzt. Mir ging es eher darum, daß es unsinnig ist, etablierte, vorhandene und verstandene 8-Bit Technik rauszuwerfen, nur weil der gerade ausprobierte CM3 ein paar Dinge besser kann.
Meister Propper schrieb: > Wozu diese unsägliche Library? Weil niemand nachher mehr diesen Register-Sch*** lesen kann. Logisch, oder? :-) Oder soll alles so aussehen, wie mein Kot von 7 Jahren auf dem ARM7TDMI ? Da schüttelt es einen nur.... was habe ich mir einen abgebrochen damals mit "Registern" :-( Und 14 Tage später schon nicht mehr gewusst was ich da gemacht habe.
Christian J. schrieb: > Die Mini Board habe ich jetzt für 3,65 / > Stück bei aliexpresss bestellt, billiger gehts nicht mehr. Wucherpreis :D Gibts auch für ca. 2,35€ inkl. Versand
chris schrieb: > Wucherpreis :D > Gibts auch für ca. 2,35€ inkl. Versand Wooooo? Da hast Du ja recht, das ist purer Wucher, wenn es die noch 30% günstiger gibt! ;-)
http://de.aliexpress.com/item/STM32F103C8T6-ARM-STM32-Minimum-System-Development-Board-Module-ForArduin/32282374854.html den hatte ich auch schon im Markt/China Schnäppchen Thread gepostet, kratzt gerade wieder an der 2€ Marke. Habe dort auch schon zweimal bestellt. Und sein Lager kauft ihr glaube ich auch nicht so schnell leer... Und da gibt es Leute die wollen 5€ für den nackten ausgelöteten Chip haben ;-)
Ollus schrieb: > Ich hab gestern mal probiert, der > STM32F030F4P6 lacht einen auch mit 32kB Flash an. Und bei dem wird > bestimmt nix selektiert. Der Hack würde sich unter Umständen auf jeden Fall lohnen, da es den F030 im TSSOP20 Gehäuse ja gar nicht mit 32kB zu kaufen gibt. Der wäre sozusagen unbezahlbar ;) Der Preis von 0,40€ pro Stück für die 16kB Variante (beim Ali) geht aber auf jeden Fall klar. Kann man schon fast überlegen den als IO-Expander zu missbrauchen. Würde meiner Meinung nach gerade für LCDs mit HD44780 Sinn machen. Man schiebt die Daten einfach per SPI, I2C oder UART rein und der eigentliche Prozessor bleibt frei von irgendeinem "delay_us()". Außerdem könnte man noch Kontrast (direkt) und Helligkeit (per externem FET) per PWM regeln.
Christopher J. schrieb: > Ollus schrieb: >> Ich hab gestern mal probiert, der >> STM32F030F4P6 lacht einen auch mit 32kB Flash an. > > Der Hack würde sich unter Umständen auf jeden Fall lohnen, da es den > F030 im TSSOP20 Gehäuse ja gar nicht mit 32kB zu kaufen gibt. Der wäre > sozusagen unbezahlbar ;) Es gibt den STM32F031F6P6 im TSSOP20 mit 32kB. Der hat im Vergleich zum STM32F030F4P6 auch noch den Timer 2 (32Bit) der dem 030 fehlt. Ich vermute jetzt mal daß die beide mit der selben Maske hergestellt werden. Vielleicht kann man beim 030 ja jetzt nicht nur 32 kb Flash, sondern auch den Timer 2 benutzen? > Kann man schon fast überlegen den als IO-Expander > zu missbrauchen. Würde meiner Meinung nach gerade für LCDs mit HD44780 > Sinn machen. Man schiebt die Daten einfach per SPI, I2C oder UART rein für solche einfachen Aufgaben nehme ich den sehr gerne. Ist ja deutlich günstiger und flexibler als I2C-Expander wie z.B. der MCP23008. Das einzige was u.U. zum Problem wird ist daß ich zusätzlich einen Levelshifter brauche um 5V-Peripherie anzusteuern.
Gerd E. schrieb: > Es gibt den STM32F031F6P6 im TSSOP20 mit 32kB. Der hat im Vergleich zum > STM32F030F4P6 auch noch den Timer 2 (32Bit) der dem 030 fehlt. Ich war irgendwie irrtühmlicherweise die ganze Zeit davon ausgegangen, dass der F030F4P6 der einzige STM32 im TSSOP20 Gehäuse ist. Danke für den Hinweis. Gerd E. schrieb: > Ich vermute jetzt mal daß die beide mit der selben Maske hergestellt > werden. Das würde auf jeden Fall Sinn machen.
CubeMX kann nach Gehäusen filtern, anbei eine Auswahl von "lötbaren" Gehäusen.
Kurze Zwischenfrage: Welche IDE benutzt ihr zum Programmieren der STMs? Die IAR evulation license ist begrenzt auf 8kbyte Code. Das reicht natürlich für die 8-bit STMs aber für ARM Cortex dann bei größeren Sachen nicht mehr.
:
Bearbeitet durch User
Max M. schrieb: > Welche IDE benutzt ihr zum Programmieren der STMs? Beitrag "Wenn die IDE die Controllerauswahl bestimmt."
Angehängte Dateien:
-
Unbenannt.JPG
280 KB
Max M. schrieb: > Kurze Zwischenfrage: Welche IDE benutzt ihr zum Programmieren der STMs? > Die IAR evulation license ist begrenzt auf 8kbyte Code. Das reicht > natürlich für die 8-bit STMs aber für ARM Cortex dann bei größeren > Sachen nicht mehr. Du, das würde hier in Glaubenskriege ausarten. Ohne IDE bist Du kompatibel zu jedem, große Projekte werden auch meist ohne IDE gemacht, zb Multikopter Software wie OpenPilot, PixHawk usw. damit sie eben JEDER kompilieren kann. Naja fast, denn cmake ist schon ne Hürde für einige IDE's, in EmBitz geht das gar nicht. Und es sollte sich herumgesprochen haben dass CooCox (laaaaaangsam + 100% vom Internet abhägig) und EmBitz (nur Windows) und auch EmWin ohne Limitierung arbeiten, da Freeware. Ich arbeite mit EmBitz, da es nur für mich allein ist und ich mit dem ganzen Make-File Kram und tausend Compileroptionen etc. nichts zu tun habe.
Gerd E. schrieb: >>> Ich hab gestern mal probiert, der >>> STM32F030F4P6 lacht einen auch mit 32kB Flash an. [...] > Vielleicht kann man beim 030 ja jetzt nicht nur 32 kb Flash, sondern > auch den Timer 2 benutzen? Ich habs grad mal ausprobiert: Der STM32F030F4P6 hat nicht nur 32kB Flash wie Ollus oben herausgefunden hat, sondern es funktioniert auch der Timer 2 (32 Bit). Damit hat man auch auf dem STM32F030F4P6 einen 32 Bit Timer zur verfügung, was ich gerade für den Timerinterrupt sehr hilfreich finde. Ich sehe keinen Unterschied zwischen dem STM32F030F4P6 und STM32F031F6P6. Also ich finde das wertet den sowieso schon sehr günstigen STM32F030F4P6 nochmal deutlich auf. Für 39 Cent pro Stück kann man da echt nicht viel falsch machen: http://www.aliexpress.com/item//32479516689.html
Thread beobachten
Seitenaufteilung abschaltenBitte 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.