Hallo, die neuen BP, die ich erhalten haben weisen sich bei St-link mit 128kb aus. Chip sehen orgonal aus, sind sie aber sicher nicht. STM32F103C8T6 Sie lassen sich mit st-link löschen aber leider nicht mit dem Embitz Debugger beschreiben. In den Link dateien habe ich die ROMSIZE auf 128kb angehoben. Bilder habe ich angehängt. Gibt es da einen Kniff wie man das beheben kann? Gruss, Christian
Sind wahrscheinlich Fälschungen. Seit Anfang 2020 sind alle BluePill-Boards mit schlecht funktionierenden Fälschungen bestückt. Eventuell kannst du sie seriell flashen, wenn du Glück hast.
Stefan ⛄ F. schrieb: > Eventuell kannst du sie seriell flashen, wenn du Glück hast. Ja, über die Arduino IDE lassen sie sich flashen aber ich arbeite nicht mit Arduino bei STM32. Nix zu machen, auch der aktuelle st-link GDB Server will sie nicht. Da ich 10 Stück gekauft habe kriegt der ebay Fritze sie auch zurück. Grad nen Fall aufgemacht.
Christian J. schrieb: > Ja, über die Arduino IDE lassen sie sich flashen aber ich arbeite nicht > mit Arduino bei STM32. Die haben einen seriellen Bootloader, den du mit Software von ST nutzen kannst. Setze dazu Boot0=HIGH. Damit meine ich nicht den (zweiten) Arduino Bootloader im Flash.
Stefan ⛄ F. schrieb: > Die haben einen seriellen Bootloader, den du mit Software von ST nutzen > kannst. Und was hat das mit der SWDIO Schnittstelle zu tun? Ist alles witzlos, wenn nicht das JTAG Debug Interface nutzbar wird. Das mit dem Jumper habe ich mal für ausgesperrte Chips benutzt, damit die wieder beschreibar wurden. Es ist zum k*** mit diesen ganzen Fake Chips inzwischen! Embitz hat einen eigenen st-link Server von 2016 eingebaut. Mit dem neuen ist das gar nicht zu machen, der bricht direkt ab, selbst bei den 64k versionen. Und leider so schnell dass man nichts sieht. Ich frickel den jetzt nochmal drauf.... 30 Minuten gebe ich mir noch das Teil zum sprechen zu bringen... So, Release flashen lässt er sich aber nicht debuggen. St-Link habe ich ja als eigene Anwendung unter Tools installiert. Der Debug Server ist aber eine andere Anwendung aus dem Hause ST.
Ok, die 128kb sind jedenfalls echt, ein testfile mit 128kb lässt sich flaschen und verify'en. Noch schöner wenn es sich auch debuggen liesse, mit 128kb wären alle meine Sorgen gelöst, da ich inzwischen bei 58kb bin mit meiner Anwendung. Edit: Nix zu machen auch nicht mit einem Testprojekt und einer 128kb Type. Dann meckert er die Core-ID an, dass die nicht stimmt.
Mach einen zur BlackMagicProbe per seriellem Flash und programmier den Rest damit, wär potentiell eine Möglichkeit die Dinger mit SDW-Interface zum Laufen zu bekommen.
Dazu hier: Beitrag "Black Magic Probe auf ST Link v2 clone "baite"" Es handelt sich übrigen i.A. um einen CS32F103C8T6, der eine andere ID hat. (0x2ba01477 statt 0x3ba00477). Wenn Du diese in den Tiefen Deiner Embitz Konfiguration einstellen kannst, wäre dies eine Möglichkeit. Zum Thema (u.A.): Beitrag "STM32F103C8T6 - Fälschung von ST bestätigt"
Christian J. schrieb: > Und was hat das mit der SWDIO Schnittstelle zu tun? Nichts. Wenn dir diese Schnittstelle wichtig ist, dann schreibe das besser bevor du mangels Infos schlechte Antworten bekommst die dich verärgern. > Ist alles witzlos, wenn nicht das JTAG Debug Interface nutzbar wird. Genau genommen kannst du mit dem SWD Interface auch kein JTAG machen, das ist wieder eine andere Schnittstelle, deren Pins sich nur zufällig mit SWD überlappen. Aber ich verstehe was du meinst: Du möchtest debuggen. > Es ist zum k*** mit diesen ganzen Fake Chips inzwischen! Allerdings. Die Händler sollten ehrlich angeben, was sie da verkaufen. Dann kann sich auch ggf. drauf einlassen und mit den dazu passenden Datenblättern arbeiten.
Stefan ⛄ F. schrieb: > Die Händler sollten ehrlich angeben, was sie da verkaufen. Wobei ich mal behaupte, das dies bei den Elektronikhändlern in China auch so ist. Dummerweise verkaufen dort halt auch Textilhändler Elektronikteile.
Ich fürchte, dass die jetzt erstmal die ganzen schlechten Fälschungen so lange verkaufen, bis es keine mehr gibt. Erst dann wird Platz frei für neue Boards (eventuell mit STM32F303). Off-Topic: Neulich ist mir aufgefallen, dass die Chinesen gerade den Markt mit Sets zum Sticken überfluten. Wenn man nach "diy kit" sucht, kommt man in sämtlichen Shops auf Unmengen runder Ringe aus Holz mit Tüchern und bunten Fäden. Als gäbe es nichts anderes mehr.
Stefan ⛄ F. schrieb: > Ich fürchte, dass die jetzt erstmal die ganzen schlechten Fälschungen so > lange verkaufen, bis es keine mehr gibt. Jetzt mal eine Frage: Sind das wirklich Fälschungen mit STM Logo und Beschriftung oder steht da CS32F103C8T6 drauf? Bis jetzt war es bei mir nämlich immer so: Wenn STM draufsteht ist da auch STM drin.
Andreas B. schrieb: > Bis jetzt war es bei mir nämlich immer so: Wenn STM draufsteht ist da > auch STM drin. Dann hattest du Glück. Ich hatte auch Glück, das war aber Ende 2019. Von dem Vorrat zehre ich noch. Wann hast du deine "guten" gekauft?
STM war schon länger her. Diejenigen, die CS32F103C8T6 drauf haben, sind auch nicht mit STM beschriftet. Tip: Beim Blackpill sind noch die originalen STM32F411CEU6 drauf. (Jedenfalls war das vor 2 Monaten noch so). Man kann hier von Täuschen sprechen, wenn die Dinger als STM verkauft werden. Fälschen ist was anderes.
Na, dann bin ich ja mal gespannt..... ich will ihm die 10 Pillen zurückschicken. Die Chipse sind übrigens mit ST Schriftzug und ST Logo beschriftet, wobei das letzte auf China hindeutet. STM32F103C8T6 GH209 CHN215 PS: Den Versuch die zahlreichen Versinen der 103er bei Embitz zu testen habe ich hinter mir. Die T6 benutzt mit 128kb. Tut es alles nicht. Durch die Abfrage der Core-Id in der st-link Software wird das alles geblockt. Nur bei openocd lässt die sich einstellen aber das kriege ich leider nicht zum Laufen weil ich nicht weiss wie.....
Christian J. schrieb: > Nur bei openocd lässt die sich einstellen aber das kriege ich leider > nicht zum Laufen weil ich nicht weiss wie..... Bei Linux Mint 20 ist es: /usr/share/openocd/scripts/target/stm32f1x kopieren nach cs32f103c8t6.cfg dort nach: set _ENDIAN little einfügen: set CPUTAPID 0x2ba01477 dann aufrufen mit: -f target/cs32f103c8t6.cfg
Andreas B. schrieb: > Bei Linux Mint 20 Leider vor 1 Jahre mangels Notwendigkeit vom Rechner geflogen. Sehr schade aber Linux war zu wenig in Benutzung.
Mag ja sein, aber Win wird das ja wohl ähnlich haben. Die Verzeichnisse sind halt nur andere. Bei mir ist Win halt nicht notwendig. ;-)
Andreas B. schrieb: > Es handelt sich übrigen i.A. um einen CS32F103C8T6, der eine andere ID > hat. (0x2ba01477 statt 0x3ba00477). Das ist so nicht ganz korrekt. Bei 0x2ba01477 handelt es sich nicht um die ID irgendeines speziellen Controllers (CS32F103C8T6), sondern um die ID des Cortex-M Kerns. Genau genommen ist es der Wert im SW-DP Register und prinzipiell müsste dieser Wert sogar für einen Cortex M4 stehen. Fest steht jedenfalls erstmal nur, dass es kein original STM32 ist. Ein CKS32 kann es meiner Meinung nach aber auch nicht sein, weil der tatsächlich nur 64kB Flash hat.
Weiss ein Embitz user vielleicht wie man das hier so aufsetzt für Source Level Debugging? Da wäre eine Anleitung für Dummies echt nett! Ist ein alternativer Debug Server, EBlink. Und vielleicht ist es Zeit den alten raus zu werfen, der ja auch von 2016 ist. https://github.com/EmBitz/EBlink
Christopher J. schrieb: > Andreas B. schrieb: >> Es handelt sich übrigen i.A. um einen CS32F103C8T6, der eine andere ID >> hat. (0x2ba01477 statt 0x3ba00477). > > Das ist so nicht ganz korrekt. Bei 0x2ba01477 handelt es sich nicht um > die ID irgendeines speziellen Controllers (CS32F103C8T6), sondern um die > ID des Cortex-M Kerns. Genau genommen ist es der Wert im SW-DP Register > und prinzipiell müsste dieser Wert sogar für einen Cortex M4 stehen. > > Fest steht jedenfalls erstmal nur, dass es kein original STM32 ist. Ein > CKS32 kann es meiner Meinung nach aber auch nicht sein, weil der > tatsächlich nur 64kB Flash hat. Wahrscheinlich Apex Micro wie bei meinen... Pille
Ich habe Anfang des Jahres beim Ali original STM32 Blue Pill bekommen. Es war ein Händler WeAct Studio. https://de.aliexpress.com/item/1005001474741936.html?gps-id=pcStoreJustForYou&scm=1007.23125.137358.0&scm_id=1007.23125.137358.0&scm-url=1007.23125.137358.0&pvid=2d706a46-7de6-4af3-9091-65979b64925d&spm=a2g0o.store_home.smartJustForYou_6000147819213.3 Die letzten Bewertungen zeigen auch dass Original Chips verwendet werden. Es gab hier im Forum aber auch jemand, der angeblich kein Original von denen bekommen hat. Da waren aber noch beide Varianten im Shop erhältlich, also original und nicht. Das war explizit ausgewiesen. Vielleicht fragst du dort bei dem Shop mal und bei positiver Meldung bestellst du dort.
:
Bearbeitet durch User
Stefan ⛄ F. schrieb: > Dann hattest du Glück. Ich hatte auch Glück, das war aber Ende 2019. Von > dem Vorrat zehre ich noch. Stefan, hast du jemals versucht EBlink Debug Server mit Embitz 1.11 zum Laufen zu kriegen? Ich habe da gestern alles versucht. Er meckert die Parameterliste an, -I und -S würden fehlen. Ich habe diese Parameter überall versucht einzutragen aber scheinbar wird diese Liste nicht beim Aufruf mitgegeben. Für sich allein lässt sich das Teil mit dem STM32 über cmd verbinden. Alles verscuht, mi Generic Device und auch dem EB Plugin was man sich runterladen kann. So wie beschrieben im Embitz Forum geht es jedenfalls nicht.
Christopher J. schrieb: > Das ist so nicht ganz korrekt. Bei 0x2ba01477 handelt es sich nicht um > die ID irgendeines speziellen Controllers (CS32F103C8T6), sondern um die > ID des Cortex-M Kerns. Genau genommen ist es der Wert im SW-DP Register > und prinzipiell müsste dieser Wert sogar für einen Cortex M4 stehen. Dann hätte der TO ja einen M4 Kern. Da die beschriebene Vorgehensweise bei mir gut funktioniert hat, kann ich mir das nicht so recht vorstellen. Christian J. schrieb: > So wie beschrieben im Embitz Forum geht es jedenfalls nicht. Hmm, bevor Du Dir jetzt einen Wolf suchst, würde ich es ja erst mal mit originalen STM versuchen. Eine Baustelle nach der anderen .....
Andreas B. schrieb: > Hmm, bevor Du Dir jetzt einen Wolf suchst, würde ich es ja erst mal mit > originalen STM versuchen. Eine Baustelle nach der anderen ..... Tja, die 128kb lassen sich ja flashen mit st-link. Habe ja eine dummy Datei eingespielt und verified. Null Fehler, die sind echt! Und die 12kb reizen mich eben, da ich damit alle Probs los wäre. Und Eblink hat sicherlich nicht diese nervigen Einschränkungen. Aber da ich keine Ahnung habe was Embitz da für einen command string zusammenbau ist das nur Stochern im Nebel. st-link wird ja mitgeliefert und openocd aber das läuft auch nicht. Blinkt nur kurz was auf und dann ist das Fenster weg. Das ST-Link läuft mit diesen China Dongeles ja auch nur so "lala" Ich habe etliche Abstürze, die durch ziehen und stecken des Dingles wieder weg sind. Nach einem Debug Lauf scheitert der Relase Lauf, da muss man mit st-link wider "freischalten" usw. Habe ich mich aber dran gewöhnt.
Christian J. schrieb: > Tja, die 128kb lassen sich ja flashen mit st-link. Ich dachte, es ginge Dir um das debuggen. So hatte ich das Anfangs verstanden. Schau Dir wirklich mal Black magic probe an.
Andreas B. schrieb: > Schau Dir wirklich mal Black magic probe an. Teures Ding. Und was ist damit anders? st-link ist ja auch ein swdio debugger. Spielt es mit meinem Embitz zusammen? Denn ohne ein Interface, was die Kommandos der IDE umsetzt und die Rückmeldungen auswertet nützt das leider alles nichts. Debug Server sind komplexe Tools. Und Kommandozeilen-Debugging kommt im Jahre 2021 echt nicht mehr in Frage.
Christian J. schrieb: > Teures Ding. Öhm, ich habe das auf ein Fake STM-link aus der Bucht daraufgeflasht. Kosten <5€. Du hast Dir noch nicht mal die Mühe gemacht, den o.a. Link zu lesen. Ich bin damit raus.
Andreas B. schrieb: > Öhm, ich habe das auf ein Fake STM-link aus der Bucht daraufgeflasht. > Kosten <5€. > Du hast Dir noch nicht mal die Mühe gemacht, den o.a. Link zu lesen. Ich > bin damit raus Auch das sagt mir nichts, wozu das Ding gut ist und ob man es in eine IDE integrieren kann, die Source Level Debugging im C Code + Asn und Life Watches und Data Breakpoints. Ebensowenig wie die zig andere Artikel darüber. Nur dass manche Leute sich da irre Kommandozeilenschlachten abliefern a la Jahr 2000 wo das noch üblich war und man mich beruflich bei Renesas mit dem ARM7TDMI quälte für den die ersten Toolchains gebaut wurden. Denn alleion für das st-link gbt es für den laien kaum verständliche Scripte in der IDE, die genau das machen: Ein Interface herstellen. Mein Gehämmer auf den Tasten und Mausgeklicke umwandeln in DBG Server Befehle und auslesen der Rückmeldungen.
Christian J. schrieb: > a la Jahr 2000 wo das noch üblich war > und man mich beruflich bei Renesas mit dem ARM7TDMI quälte für den die > ersten Toolchains gebaut wurden. dann ist es um so unglaublicher was du da für einen Unfug schreibst. EmBitz unterhält sich mit dem GDBServer, da hat man nix mit zu tun. Man muss dem nur beim Start mitteilen wie er sich mit dem Target verbinden soll. Und das wird auch EmBitz können.
Johannes S. schrieb: > Und das wird auch EmBitz können. Ja, vor 20 Jahren.... Embitz kann das! Aber dafür muss man Scripte schreiben .... lassen wir das, Thema ist durch. Die Klone fliegen in die Tonne bzw wrte ich noch auf die 42 Euro, die ich von ebay zurück will weil der Verkäufer sich weigert, ich kaufe mit echte 128kb Chips bei Mouser und löte die drauf.
Christian J. schrieb: > ich kaufe mit echte 128kb Chips bei > Mouser und löte die drauf. da hsst du Zeit dich zu beruhigen, die sind ausverkauft...
Johannes S. schrieb: > da hsst du Zeit dich zu beruhigen, die sind ausverkauft... Grumpf !! :-((((( https://www.amazon.com/32-Bit-Stm32F1-Stm32F103-Lqfp100-Stm32F103Vbt6/dp/B0838WQ1BC
Stefan ⛄ F. schrieb: > Allerdings. Die Händler sollten ehrlich angeben, was sie da verkaufen. Ach Stefan, das machen die doch. Die handeln mit allem, von Babysocken bis Radios oder Drehmeißeln. Da wird eben vom Großhändler eine Palette "BluePills" eingekauft und dann eben als "BluePill" verkauft. Ob das eine bestückte Leiterplatte ist oder was zum Lutschen, das weiß der Händler schlichtweg nicht. Abgesehen davon ist das Herumrülpsen des TO ein bissel sinnlos. Die Dinger haben gewiß einen Cortex-Kern, eine STM-ähnliche Peripherie und sehr wahrscheinlich auch einen eingebauten Bootlader. Abgesehen davon sollten sie nur 64K an Flash haben, wenn sie denn kompatibel zum besagten STM32F103C8T6 sein wollen. Da etwa 128K zu erwarten, ist eigentlich ne Dreistigkeit. Der JLink von Segger kann die STM32 auch entsperren, was wohl oft genug vor dem ersten Programmieren notwendig zu sein scheint. Ob das bei dem Geschirre von ST angesichts einer unzutreffenden ID im Chip auch geht, ist fraglich. Der Bootlader kann das übrigens auch tun, allerdings habe ich bei einigen Typen festgestellt, daß es beim Bulk-Erase dort zu einem Latchup kommt. Also Spannung aus und wieder ein und der Chip ist geputzt. Mein kleines PC-Programm zum Benutzen des Bootladers kann ja jeder hier runterladen so er mag. Abgesehen davon frag ich mich, wozu jemand ein bis zwei Dutzend solcher Boards braucht, wenn er gesteigerten Wert auf das Debuggen legt. Dazu braucht man ja schließlich nur einen einzigen µC und damit nur ein Board. Erst wenn alles geht braucht man dann die zwei Dutzend für die Bastel-Kleinserie. W.S.
Christian J. schrieb: > Auch das sagt mir nichts, wozu das Ding gut ist Das findet man im 2. Eintrag einer bekannten Suchmaschine (die einem zum entsprechenden WIKI führt) wenn man "Black Magic Probe" als Suche eingibt. Aber wer nicht will, der will nicht. Christian J. schrieb: > Nur dass manche Leute sich da irre > Kommandozeilenschlachten abliefern Bla Bla. Noch ein Beweis von nix gelesen. Christian J. schrieb: > Denn alleion für das st-link gbt es für den laien Ja, ein Wunder: Die Entwicklung mit 32 Bit Controllern ist nun mal nicht für den Laien gedacht. Ich sehe schon, das wird nichts. W.S. schrieb: > Da wird eben vom Großhändler eine Palette > "BluePills" eingekauft und dann eben als "BluePill" verkauft. Ob das > eine bestückte Leiterplatte ist oder was zum Lutschen, das weiß der > Händler schlichtweg nicht. Krass formuliert, aber wo Du Recht hast, hast Du Recht. ;-) W.S. schrieb: > Da etwa 128K zu erwarten, ist > eigentlich ne Dreistigkeit. Haben die Clones fast immer. Kann man also erwarten.
:
Bearbeitet durch User
Johannes S. schrieb: > da hsst du Zeit dich zu beruhigen, die sind ausverkauft... Hier ist die Lösung, man muss st-link neu kompileren mit einer anderen core-id in stm32.h. Habe nur leider keine Umgebung sowas zu machen. Nur Windows 7 ohne alles. https://github.com/stlink-org/stlink
Stefan ⛄ F. schrieb: > Ich fürchte, dass die jetzt erstmal die ganzen schlechten Fälschungen so > lange verkaufen, bis es keine mehr gibt. Erst dann wird Platz frei für > neue Boards (eventuell mit STM32F303). Unter ebay häufen sich dafür zunehmend "black pills" mit STM32F401 und STM32F411: https://www.ebay.de/sch/i.html?_nkw=STM32F401 Leider ohne CAN.
900ss D. schrieb: > Ich habe Anfang des Jahres beim Ali original STM32 Blue Pill bekommen. > Es war ein Händler WeAct Studio. Herzlichen Glückwunsch! Du bist der erste - kein Scherz.
Christian J. schrieb: > Stefan, > hast du jemals versucht EBlink Debug Server mit Embitz 1.11 zum Laufen > zu kriegen? Nein
Philipp B. schrieb: > Unter ebay häufen sich dafür zunehmend "black pills" mit STM32F401 und > STM32F411: > https://www.ebay.de/sch/i.html?_nkw=STM32F401 Wie geil ist das denn? GEIL-O-MAT! Erst mal 2 Bestellt, 256kb Flash sind ja ne andere hausnummer als diese popeligen 64kb mit 20kb RAM. Gucken ob da noch irgendwelche StdPeriph Libs passen und eine CMSIS dazu. Nur sind die 4er, wie vom 429 bekannt auch ne Nummer komplexer, schon was das RAM angeht.
Hallelujah! Aber in einem Jahr... Wenn der Logger die Tracks noch in Google Earth in HD anzeigen soll... Da gibts zum Glück immer noch fettere Controller :) Wenn du jetzt noch ein gutes OS dafür verwenden würdest. Aber nein, nicht schon wieder :))
Pille schrieb: > Wahrscheinlich Apex Micro wie bei meinen... Ja, vermutlich... Andreas B. schrieb: > Christopher J. schrieb: > >> Genau genommen ist es der Wert im SW-DP Register >> und prinzipiell müsste dieser Wert sogar für einen Cortex M4 stehen. > > Dann hätte der TO ja einen M4 Kern. > Da die beschriebene Vorgehensweise bei mir gut funktioniert hat, kann > ich mir das nicht so recht vorstellen. Auch das ist gut möglich. Der M4-Kern beschwert sich ja nicht über M3-Instruktionen, nur andersherum. Müsste halt mal einer testen ob der bei M4-Opcodes im Fault-Handler landet. Christian J. schrieb: > Wie geil ist das denn? GEIL-O-MAT! Erst mal 2 Bestellt, 256kb Flash sind > ja ne andere hausnummer als diese popeligen 64kb mit 20kb RAM. Joa, wenn man auf den CAN verzichten kann (was wohl die meisten können), dann sind die F401/F411-Boards definitiv in allen belangen besser und nur unwesentlich teurer als ein F103C8. > Nur sind die 4er, wie vom 429 bekannt auch ne Nummer komplexer, schon > was das RAM angeht. Von einem F429 sind die F411 und F401 (was die "Ausstattung" angeht) meilenweit entfernt, dafür aber eben auch deutlich günstiger. Eine Sache wollte ich aber noch loswerden: Du erwartest, dass dein Setup, bestehend aus "Billigboard" und "Debuggerclone" für jeweils "einsfuffzich" mit deiner (closed-source-one-man-show-)Lieblings-IDE zusammenwerkelt, mit einer Herstellerlibrary die (wie auch die IDE) seit mehreren Jahren nicht mehr gepflegt wird, bist dir aber "zu fein" die Zeit zu investieren um die zugrundeliegenden Zusammenhänge zu erarbeiten um ggf. irgendwo ein Skript anzupassen? Sorry aber das passt für mich irgendwie nicht zusammen. Ich hab ja gar nichts gegen die ganzen Chinaboards, ganz im Gegenteil, ich habe mich als Student riesig daran erfreut, was man für so kleines Geld bekommt. Wenn du aber schreibst, dass du vor 20 Jahren schon für Renesas gearbeitet hast, dann kann ich mir einfach beim besten Willen nicht vorstellen, wie dich ein Nucleo-Board vom Reichelt (etwa L432KC) in den finanziellen Ruin treiben sollte. Das bedeutet für dich doch nicht - im Gegensatz zum Studenten - das du die kommenden fünf Tage "Nudeln mit Tomatensauce" essen musst um das Geld wieder "hereinzusparen". Sorry, wenn es vielleicht etwas persönlich wurde aber hier mein völlig ernst gemeinter Rat: Kauf dir ein Nucleo-Board deiner Wahl, nimm die Hersteller-IDE dazu und werde glücklich damit. Du hast ein garantiert funktionierendes Board, mit einem garantiert funktionierenden Debugger und einer garantiert funktionierenden IDE und das ganze kostet dich vielleicht 15-20€. Und bitte sag jetzt nicht, dass du mit einer Eclipse-IDE überhaupt nicht klarkommst, weil die ja so langsam ist, wenn du auf der anderen Seite super damit klarkommst den Debugger ab- und wieder anzustecken, weil der sich zwischenzeitlich aufhängt.
Christopher J. schrieb: > Sorry, wenn es vielleicht etwas persönlich wurde aber hier mein völlig > ernst gemeinter Rat: > Kauf dir ein Nucleo-Board deiner Wahl, nimm die Hersteller-IDE dazu und > werde glücklich damit. Du hast ein garantiert funktionierendes Board, > mit einem garantiert funktionierenden Debugger und einer garantiert > funktionierenden IDE und das ganze kostet dich vielleicht 15-20€ Das weiss ich aber da ist die Sache mit dem Stromverbrauch und der Größe halt.... naja, man versucht hat das Maximale aus allem heraus zu quetschen. Habe ja noch reichlich Disco's, die steckt man auch einfach ein und fertig. Ging vor 5 Jahren ja auch, wie man sieht. Bei bedarf an 407ern, ich habe noch 2 übrig. Aber hey, ich hab da noch was.... Z80! Klappt bestimmt auch damit, eine UART, sorry SIO hat er zumindest :-) Und 1.5A kriegen wir auch noch irgendwoher... Klar kenne ich Eclipse... es ist schweinelangsam, Java eben. Und mal "eben" ein Debugger Skript anpassen kann auch nur der, der sich da sehr tief einarbeitet. Habe mir das mal angeschaut, trivial ist das nicht.
Andreas B. schrieb: > W.S. schrieb: >> Da etwa 128K zu erwarten, ist >> eigentlich ne Dreistigkeit. > Haben die Clones fast immer. Kann man also erwarten. Nein, haben die Clone fast nie! Die Clones habe meist ein externes SPI Flash, genau in der Groesse wie angegeben. Bei STM32F103x8 ist es anders. Das ist der gleiche Chip wie STM32F103xB.
Christian J. schrieb: > Das weiss ich aber da ist die Sache mit dem Stromverbrauch und der Größe > halt.... Naja, ein Nucleo-L432KC ist definitv nicht größer als ein Bluepill-Board aber - richtig konfiguriert (Debugger abklemmen, mittels Lötbrücken, etc.) - definitiv deutlich sparsamer. > Klar kenne ich Eclipse... es ist schweinelangsam, Java eben. Ist nicht rasend schnell aber sicher besser als Debugger ab- und wieder anzustöpseln. Performantere IDEs (die ich kenne, z.B. QtCreator) brauchen mehr "Eigeninitiative" (https://doc.qt.io/qtcreator/creator-developing-baremetal.html). Uwe B. schrieb: > Andreas B. schrieb: > >> W.S. schrieb: >>> Da etwa 128K zu erwarten, ist >>> eigentlich ne Dreistigkeit. >> Haben die Clones fast immer. Kann man also erwarten. > Nein, haben die Clone fast nie! Die Clones habe meist ein externes SPI > Flash, genau in der Groesse wie angegeben. Bei STM32F103x8 ist es > anders. Das ist der gleiche Chip wie STM32F103xB. Ich dachte lediglich Gigadevices hätte das mit dem externen SPI-Flash (im Package).
Moin, - Christopher J. schrieb: > Eine Sache wollte ich aber noch loswerden: > Du erwartest, dass dein Setup, bestehend aus "Billigboard" und > "Debuggerclone" für jeweils "einsfuffzich" mit deiner > (closed-source-one-man-show-)Lieblings-IDE zusammenwerkelt, mit einer > Herstellerlibrary die (wie auch die IDE) seit mehreren Jahren nicht mehr > gepflegt wird, bist dir aber "zu fein" die Zeit zu investieren um die > zugrundeliegenden Zusammenhänge zu erarbeiten um ggf. irgendwo ein > Skript anzupassen? > Sorry aber das passt für mich irgendwie nicht zusammen. Und vor allen Dingen, dass man heute einen Orginal-Debugger fuer 50,00EUR kaufen kann, eine vom Hersteller unterstuetzte Entwicklungsumgebung ohne vierstelligen Obolus, ein Orginal-Board fuer 20 - 50EUR. Das ist alles kein Geld. Auch im Hobby nicht. Einige meckern schon auf einem sehr hohen Niveau. Auch die Webinars von ST (fuer Umme) haette ich gerne gehabt, vor 20 Jahren. Gruesse Th.
Thomas W. schrieb: > Das ist alles kein Geld. Auch im Hobby nicht. Einige meckern > schon auf einem sehr hohen Niveau. Also ich weiss nicht ob das kein Geld ist? Ich würde ja gerne die emIDE verwenden, weil die gepflegt wird aber da kann man eben nur einen J-Link Debugger eintragen und das ist der von Segger. Und bei dem Preis ... für Hobby? Ok, grad gesehen, den J-Link Edu Basic, 58 Euro.... mal angefragt ob der kompatibel ist zu emIDE.... und wenn dann geschieht der Umstieg noch diese Woche.
Christian J. schrieb: > Und bei dem Preis Es gibt doch den J-Link EDU. Der kostet ca. 50€. Ist dann nur für none commercial. Der sollte doch auch mit der IDE laufen.
900ss D. schrieb: > Christian J. schrieb: > >> Und bei dem Preis > > Es gibt doch den J-Link EDU. Der kostet ca. 50€. Ist dann nur für none > commercial. Der sollte doch auch mit der IDE laufen. und nicht zu vergessen den Edu-Mini für die Hälfte oder den J-Link Lite auf einem Nucleo-Board für "umme".
Also meinst du das tut es auch? d.h. der ist kompatibel zur Segger Software von deren Homepage? https://www.reichelt.de/in-circuit-debugger-programmierer-fuer-stm32-stlink-v3mini-p274817.html?PROVID=2788&gclid=Cj0KCQjwsLWDBhCmARIsAPSL3_3SjPYiqlDz-lECsO9evCsVWEd5WcGi8e_pO1iRs2BgZat7DeSitZwaAkYMEALw_wcB
Nein, passt nicht. Diese lite Version ist nur für die F103RB auf den ST Boards und will vermutlich auch den ST Bootloader sehen. Lizenztechnisch ist diese Version auch nur für das ST Board und nicht für externe.
Johannes S. schrieb: > Nein, passt nicht. Diese lite Version ist nur für die F103RB auf den ST > Boards und will vermutlich auch den ST Bootloader sehen. Wieso Bootloader? Die kommunizieren doch über die genormte JTAG oder SWD Schnittstelle? Oder sehe ich da was falsch? Bootloader brauchste doch nur für den ganzen Arduino Kram, der über RS232 eingespielt wird. Intel Hex Files, die in-the-field eingespielt werden. Früher hatten wir den Wiggler, heute gibt es diese USB To JTAG Dinger ja überall auf Basis eines ftdi Chips oder uC der USB anbindet. Dann kaufe ich mir das Ding von Segger und gut is.
Christian J. schrieb: > Dann kaufe ich mir das Ding von Segger und gut is. ?? Christian J. schrieb: > Andreas B. schrieb: >> Schau Dir wirklich mal Black magic probe an. > > Teures Ding. <5€
Christian J. schrieb: > Also meinst du das tut es auch? Also der ist nicht von Segger, den meine ich nicht. Ich hatte die Produkte genannt von Segger(!) die ich meinte. Vielleicht fragst du einfach bei Segger nach? Aber ich würde davon ausgehen, dass deren Produkte zu IDE kompatibel sind. Wird vermutlich auch auf deren Homepage stehen. Aber selber nachschauen ist ja nicht modern ;)
:
Bearbeitet durch User
Uwe B. schrieb: > Nein, haben die Clone fast nie! Meine hatten bis jetzt immer 128kB. (Bei knapp 10 Stck aus verschiedenen Quellen). Allerdings hatten meine originalen STM32F103C8T6 ebenfalls alle 128kB. Vielleicht bin ich aber auch nur ein Glückspilz.
Christian J. schrieb: > Ich würde ja gerne die emIDE verwenden, weil die gepflegt wird... Sicher das du emIDE meinst? http://emide.org/changelog.php Nimm doch einfach Embedded Studio: https://www.segger.com/products/development-tools/embedded-studio/ Welche IDEs den J-Link unterstützen findest du hier: https://www.segger.com/products/debug-probes/j-link/technology/ides/overview-of-supported-ides/
Christian J. schrieb: >> Nein, passt nicht. Diese lite Version ist nur für die F103RB auf den ST >> Boards und will vermutlich auch den ST Bootloader sehen. > > Wieso Bootloader? Die kommunizieren doch über die genormte JTAG oder SWD > Schnittstelle? Oder sehe ich da was falsch? Bootloader brauchste doch > nur für den ganzen Arduino Kram, sehr wirre Gedanken, dabei ist es doch so einfach: jeder STLink hat einen USB Bootloader für Firmwareupdates (die auch wirklich häufig gebraucht werden damit er mit den aktuellen STM Werkzeugen funktioniert). Und das JLink Tool nutzt den Bootloader eben um die alternative Firmware zu flashen oder um das wieder auf original zurückzustellen. Aber halt nur für STM Boards und zur Verwendung mit diesen gedacht. Für die Basteleien mit den China Boards fängt es wie geschrieben wurde mit dem EDU oder mini an.
Uwe B. schrieb: > Andreas B. schrieb: > >> W.S. schrieb: >>> Da etwa 128K zu erwarten, ist >>> eigentlich ne Dreistigkeit. >> Haben die Clones fast immer. Kann man also erwarten. > Nein, haben die Clone fast nie! Die Clones habe meist ein externes SPI > Flash, genau in der Groesse wie angegeben. Falsch! Genau Einer der in Frage kommenden "Clone" (sind ja Keine) hat das was Du beshreibst, das ist der Gigadevice GD32F103C8T6. Alle Anderen haben den Falsch auf den Prozessorchip. Pille
Pille schrieb: > Falsch! Kannst du lesen? Wenn ja, dann schau mal in das DB oder RM des STM32F103C8T6 und du wirst dort lesen können, daß dieser eben 64K an Flash hat. Punkt. Und wenn durch einen euch gnädigen Zufall da noch mehr an Flash sein sollte, der sogar benutzbar ist und nicht vom Hersteller abgeschaltet, dann darf man das eben NICHT erwarten bei einem Board, was angeblich einen STM32F103C8T6 oder einen dazu kompatiblen Chip enthält. Irgendwie ist ohnehin dieser ganze Thread irrsinnig. Da wird gierig auf Chips mit nem halben MB an Flash geschaut, immer "höher, schneller, weiter und mehr Bässe" - und dann wird so ein Zeugs auf ein Steckbrett gestopft und das ist dann das Ende der Fahnenstange. Unsereiner würde stattdessen eine Projektentwicklung erwarten, wo am Ende ein Gerät steht. Also etwas anderes als ein Drahthaufen auf'm Steckbrett. W.S.
W.S. schrieb: > Kannst du lesen? Wenn ja, dann siehst Du, daß Pille Dir in dem Punkt widersprochen hat, daß das Flash sich bei den Clones auf einem externen Flash befindet. Und auch wenn es im DB steht, wirst Du kaum Chips finden die nur 64MB haben. Das man dies bei einer professionellen Entwicklung nicht ausnützen sollte: geschenkt.
W.S. schrieb: > Also etwas anderes als ein Drahthaufen auf'm Steckbrett. und die Augen machen scheinbar auch nicht mehr mit. Der TO baut seine Schaltungen auf weiß gestrichenen Lochrasterplatinen auf. Künstlerische Freiheit würde ich das nennen wenn man sich das so an die Wand hängen möchte. Zu den Clones wurde auch schon genug geschrieben, der F103C8 hat einen Die mit 128 kB. Zu den Alternativen gibt es Datenblätter und es sind Unterschiede bekannt, CKS hat nur 64 kB und GD wirbt mit mehr Speicher und Speed weil 128 kB im RAM gepuffert werden und dann mit 108 MHz ohne Waitstates laufen. Und wenn die Chips korrekt beschriftet sind kann man das auch Nutzen. Für die 128 kB der STM32F103C8 muss man nur Tools haben die die eingebrannte Romsize ignorieren, um nix anderes ging es hier.
>>Der TO baut seine Schaltungen auf weiß gestrichenen Lochrasterplatinen >>auf. Künstlerische Freiheit würde ich das nennen wenn man sich das so an >> die Wand hängen möchte. Gedankenübertragung: Das war wirklich der Grund, das Brett hing 3 Jahre an der weissen Wand. Heizkörper Lack. Mal ne offtopic Frage: Habe jetzt 5 Stunden die ChatFat zum Laufen gekriegt und dabei wohl alle Fehler gemacht, die man machen kann. z.b. dass die SPI1 auf dem remap Pins mit I2C1 kollidiert, auch wenn diese SMAI Pin nicht benutzt wird. Und dass die SPI Pins nur teilweise mit AF angebunden werden, MISO aber als Input. Und noch so etliches mehr, weil ich alte Versionen von Datein mit neuen gemixt hatte. Ok... der Jubelschrei war bis zur Straße zu hören als mit einer neuen Karte das zu sehen war. Sogar mit dem richtigen Zeitstempel der aus dem GPS Modul gezogen wird und in die RTC wandert. Naja.... der Jubel hielt sich dann aber in Grenzen als ich die Stecker der Logic Probe endlich abzog vom SD Kartenhalter. Da kam dann wieder NO_FILESYSTEM als Fehler einer fopen Anweisung. Nach und nach den bösen Pin identifiziert, es ist der Clock. Steckt man den Stecker auf SCLK wieder an (auch ohne GND an der Probe) geht es wieder, zieht man ihn ab ist der Fehler wieder da. Lötungen auf dem Raster Board sind alle ok. SPI läuft mit 1Mhz und 4Mhz testweise. Leitung ca 4cm lang. Pins sind mit _50Mhz Flankensteilheit eingestellt. Ohne Oszi erstmal Dunkelheit, das liegt noch im Laden bzw bei Amazon. Mit der Probe sieht man ja nur ideales Rechteck. Sind diese 3.3V SD Kartenhalter vielleicht nicht so ganz ok? Gelobe Besserung... so schlecht sollen die ja nicht sein: https://www.ebay.de/itm/Owon-SDS1102-Oszilloskop-Oszillometer-Speicheroszilloskop-2CH-100MHz-1GS-s-J8G8/233954818555?hash=item3678cb39fb:g:6tgAAOSw-L9garu6
Til S. schrieb: > Sicher das du emIDE meinst? > http://emide.org/changelog.php Ist total veraltet wie ich dann auch gesehen habe. > Nimm doch einfach Embedded Studio: > https://www.segger.com/products/development-tools/embedded-studio/ > > Welche IDEs den J-Link unterstützen findest du hier: > https://www.segger.com/products/debug-probes/j-link/technology/ides/overview-of-supported-ides/ Ich habe heute bei euch den EDU bestellt und mir die Studio Version herunter geladen. Dann wird alles gut :-)
Beitrag #6649595 wurde von einem Moderator gelöscht.
Christian J. schrieb: > Steckt man den Stecker auf SCLK wieder an > (auch ohne GND an der Probe) geht es wieder, > zieht man ihn ab ist der Fehler wieder da. Was könnte die Probe beeinflussen? GND hast du ausgeschlossen. Kapazitive Last macht die Flanken der Signale flacher, reduziert Reflexionen und kurze Störspitzen. Ohmsche Last zieht die Spannung herunter, wenn der Pin floatet (nicht aktiv angetrieben wird). Diese beiden Punkte würde ich mal antesten, also mit einem Widerstand und einem 220pF Kondensator (nacheinander, nicht gleichzeitig). Dann schauen wir weiter.
Stefan ⛄ F. schrieb: > Was könnte die Probe beeinflussen? > > GND hast du ausgeschlossen. > > Kapazitive Last macht die Flanken der Signale flacher, reduziert > Reflexionen und kurze Störspitzen. Der Oszi ist auf dem Weg.... Maßnahmen: RTC Pins des PortC sind gekappt, d.h. nicht eingelötet (fiese Störquelle) Alle Pins beim Setup auf AIN gesetzt, dann die gebrauchten initialisiert. GND kontrolliert Elko + 100nf hinter den 3.3V DC/DC Wandler Alle Pins nachgelötet, CuL Draht auf Minimum gekürzt (3-4cm) Bluepill getauscht SD Card getauscht Spannung kontrolliert am 3.3V SD Steckplatz (kein 5V Adapter) SPI Frequenzen bis 1 Mhz runter Finger auf Clock oder Probekabel beheben das Problem "intermettierend", d.h. wohl nicht ganz. In älteren Breadboards waren 12Mhz die Schmerzgrenze für "Freiluftaufbau" bei der SPI. Der SD Sockel hat Serien 100 Ohm Widerstände zur Karte drin (102 Aufdruck= und 2 C's drauf. Ich tausche den Sockel dann mal, denn auch wenn ich mit dem Oszi die Flanken sehe nützt mir das nicht viel, da ich die Ursache nicht kenne. Die Datenmenge bei einem flopen mit fwrite und fclose ist leider so hoch, dass die Probe an die Grenzen kommt, das sind tausende Bytes, da sucht man sich tot. Nervig ist leider dass die FAT erst nach fclose angepasst wird, d.h. ich muss extra noch einen Power Down Mechanismus einbauen, sonst gibt es Datenmüll. Schalter an/aus wäre netter. Meine Güte, das hat schonmal funktioniert. Bei den openlog Dingern klappt es ja auch wunderbar. Wieso ausgerechnet jetzt nicht mehr?`Boaaahhhhh....
Andreas B. schrieb: > Und auch wenn es im DB steht, wirst Du kaum Chips finden die nur 64MB > haben. Erstens steht das nicht im DB des STM32F103C8T6 - und zweitens findet man eher ganz wenig bis gar keine Controller, die satte 64 Megabyte an Flash auf dem Chip haben. Warum schreibst du sowas? Bloß um auch was dazu zu schreiben? Dieser Thread und auch andere Threads sind voll von Gejammer über angebliche Inkompatibilitäten. Man will die ach so billigen BluePill-Boards in Massen ordern, die weit jenseits des normalen Bastlerbedarfes sind - ohne zu bedenken, daß da mittlerweilen aus Preisgründen eben andere Chips drauf sind, die durchaus ihren Dienst versehen können, wenn man sie so akzeptiert, wie sie eben sind. Aber nein, man will zugleich auch seine "Gewohnheiten" erfüllt sehen, also 128K, vollkompatibel zum STM32F103C8T6 und so weiter. Ich sag's nochmal: Wenn all die Jammerer zu rechten Zeiten ihre Programmiergewohnheiten dahin geändert hätten, daß sie eben weitestgehend unabhängig sind von einem einzigen Hersteller, dann hätten diese Leute anstelle herumzujammern sich einfach andere Boards machen lassen und Chips von anderen Herstellern draufgelötet oder löten lassen. Vielleicht hätte sich daraus dann auch eine Szene aus herstellerunabhängigen Treibern, Middleware usw. entwickeln können - und ich meine hier ausdrücklich nicht sowas wie CMSIS. W.S.
W.S. schrieb: > Erstens steht das nicht im DB des STM32F103C8T6 Seite 109: https://www.st.com/resource/en/datasheet/stm32f103c8.pdf
W.S. schrieb: > Man will die ach so billigen BluePill-Boards in Massen ordern, die weit > jenseits des normalen Bastlerbedarfes sind - ohne zu bedenken, daß da > mittlerweilen aus Preisgründen eben andere Chips drauf sind, die > durchaus ihren Dienst versehen können, wenn man sie so akzeptiert, wie > sie eben sind. Wenn da drin ist, was drauf steht und es auch korrekt bezeichnet verkauft wird, kann ich mich am richtigen Datenblatt orientieren. Chips die fälschlicherweise als STM32F103C8T6 beschriftet oder verkauft werden, sind nicht akzeptabel. Das war schon immer betrug und wird es auch bleiben, ganz egal wie du es zu rechtfertigen versuchst. W.S. schrieb: > zweitens findet man eher ganz wenig bis gar keine Controller, > die satte 64 Megabyte an Flash auf dem Chip haben. Ich hofee du bist klüger als dieser Satz suggeriert. Es ist doch klar wie Kloßbrühe, dass er 64kB gemeint hat. Du wolltest das nur nicht erkennen, um etwas zum meckern zu haben.
Stefan ⛄ F. schrieb: > Du wolltest das nur nicht > erkennen, um etwas zum meckern zu haben. Er hat mich schon wg. KICAD auf den Schirm. ;-)
W.S. schrieb: > Aber nein, man will zugleich auch seine "Gewohnheiten" > erfüllt sehen, also 128K, vollkompatibel zum STM32F103C8T6 und so > weiter. der TO hat gezeigt das er einen 128 kB Chip hat: Beitrag "Re: STM32F103 Bluepill mit 128kb lässt sich nicht flashen" alles andere sind wieder die typischen W.S. Interpretrationen.
Stefan ⛄ F. schrieb: > Ich hofee du bist klüger als dieser Satz suggeriert. Es ist doch klar > wie Kloßbrühe, dass er 64kB gemeint hat. Du wolltest das nur nicht > erkennen, um etwas zum meckern zu haben. Klar..... was sonst? Meine Tochter hat mir aber ihr neues Bluepill-Board mitgebracht. Ich gucke mal wieviel KB das hat und wie schnell man das takten kann :-)
Ich habe eine kurze Übersicht über diese chin. Arm Chips gefunden. Leider in Chinesisch aber Google liefert eine ganz brauchbare Übersetzung. Da wird auch dargestellt dass die Teile nicht in allen Einzelheiten den STM Chips entsprechen. Am weitesten weg vom STM103 ist wohl der der WCH der eine zusätzliche USB Schnittstelle hat. Dieses Teil ist auch mit RISC Kern verfügbar. Speziell bei WCH gibt's nur Chin. Datenblätter die haben nur den chin. Markt im Visier. Der Text enthält auch etwas nationalistische Phrasen, die sind wohl notwendig wenn ein Blog in China uberleben soll. Die Teile sind wohl für den Internen Markt gedacht, und würden nie dazu designed 100% kompatibel zu STM zu sein. Hier der Link https://www.cnblogs.com/phyger/p/14277317.html
@Stefanus: Mein Oszi lässt weiter auf sich warten. Aber die SD Geschichte hat mir keine Ruhe gelassen. Aufgabe: Verbinde 4 CuL Drähte mit einer SPI Schwierigkeitsgrad: Anfänger Bei openlog spielt das einwandfrei mit einem 328er AVR. Wieso nicht bei diesem verfluchten Pillen Board? Ich habe diesen Murks hier eingebaut: https://www.ebay.de/itm/MicroSD-Breakout-Board-fur-SD-TF-Karte-fur-Arduino-3-3V-6Pin/272215736621?hash=item3f6152812d:g:gmQAAOSwuoZgG3OA Und einfach mal die 10k Widerstände gebrückt. Weil ich dachte die liegen in Seie er 4 Leitungen. Pustekuchen, danach hatten alle Leitungen Masseschluss. Die Teile sind 10k Pulldown's! Häh wieso das? Der STM32 kann doch kaum was treiben, vielleicht 3ma pro Pin. Der AVR aber einiges mehr, 20mA schafft der. Da wird sogar SCLK noch mit einer LED belastet... sehr clevere Lösung, ein Transistor war wohl zu teuer. Da werden die Signale sicher lecker ausschauen. Hier das Vergleichsschema vonh openlog, da sind überhaupt keine Widerstände drin. Ich vermute mal, dass diese SD Cardf Klo's für Arduino gemacht wurden und auch nur da laufen sie. Jetzt mal versuchen die Brücken wieder zu entfernen an diesem winzigen Kram.... man wird eben doch älter.
Christian J. schrieb: > Bei openlog spielt das einwandfrei mit einem 328er AVR. > Wieso nicht bei diesem verfluchten Pillen Board? Ich traue mich ja kaum es zu sagen, aber: Vielleicht weil auf dem Board ein schlecht gefälschter STM32 sitzt. > Der STM32 kann doch kaum was treiben, vielleicht 3ma pro Pin. Eigentlich garantiert ST gültige Logikpegel bis 8mA und 25mA Belastbarkeit.
Stefan ⛄ F. schrieb: > Ich traue mich ja kaum es zu sagen, aber: Vielleicht weil auf dem Board > ein schlecht gefälschter STM32 sitzt. Nein.... die Daten sind ja da. Ich habe ja auch schon zwei Pillen miteinander verbunden um zu testen, wo die Grenze der Frequenz ist. Der eine ballert den anderen mit Dummys voll und der andere prüft die nur. Da war bei 12 Mhz Schicht und das kleine Transistorradio im Raum spielte auch nur noch Byte-Musik ab.
Christian J. schrieb: > Da wird sogar SCLK noch mit einer LED belastet... sehr > clevere Lösung, ein Transistor war wohl zu teuer. > Da werden die Signale sicher lecker ausschauen. Das ist schon Ok, daran wird es nicht liegen.
Stefan... Du kannst nicht eine Datenleitung auf der mit über 4 Mhz Datenlaufen mit einer LED belasten? Es sei denn Du hast ne Pumpe an dem Pin, die das locker treiben kann. Und der STM32 bringt grad mal eine Low Power LED zum Leuchten mit 150 Ohm Widerstand. Was kosten originooool Pillen und welcher Dealer verkauft den Stoff? Robotdyn hat sie ausverkauft. So, erstmal meine Tochter jetzt dran gesetzt, die hat noch junge Augen und muss trotzdem die Lupe verwenden...
Christian J. schrieb: > Du kannst nicht eine Datenleitung auf der mit über 4 Mhz > Datenlaufen mit einer LED belasten Dann muss ich wohl Geister gesehen haben, und zwar ziemlich viele. > Was kosten originooool Pillen und welcher Dealer verkauft den Stoff? > Robotdyn hat sie ausverkauft. Neulich berichtete hier im Forum jemand, er habe originale bekommen. Allerdings mit USB-C Buchse. Sie kosteten um 5 Euro. Ich glaube das war bei Amazon (sagt nicht viel aus, ich weiß).
Ok, hier ist der SD Card Plan vom freundlichen Chinesen: Was soll das mit den Pull Ups? Bei I2C ok aber wieso bei PP Ausgängen?
Ok, https://www.amazon.de/-/en/TECNOIOT-STM32F103C8T6-Minimum-Development-Arduino/dp/B07WSDYNQG/ref=sr_1_5?dchild=1&keywords=blue+pill+board&qid=1618132527&sr=8-5 hier sind die original bestätigten Boards..... aber bitte mal auf den Preis schauen!
Christian J. schrieb: > Ok, hier ist der SD Card Plan vom freundlichen Chinesen Das passt aber nicht zu der Aussage, dass es Pull-Down Widerstände seien.
Stefan ⛄ F. schrieb: > Das passt aber nicht zu der Aussage, dass es Pull-Down Widerstände > seien. Jaaaaa.... ich konnte es nicht mehr korrigieren, weil Du schneller warst...
Christian J. schrieb: > Was soll das mit den Pull Ups? macht Sinn wenn der Controller im deep sleep die IO hochohmig macht. Welche Pins werden denn für SPI benutzt? Falls PortC, waren die nicht etwas schlapper als die anderen? Und in der Initialisierung muss doch SPI auf 400 kHz reduziert werden, ist das auch drin?
Johannes S. schrieb: > Falls PortC, waren die nicht > etwas schlapper als die anderen? Poart A, weil Portc gibt es nicht beim BP (Pins muss man ziehen, da RTC hochohmig) und PortB Remap den MOSI mit dem I2C teilt (SMAI). Ansonsten überlässt man es dem Designer was dazu baut und drängt ihm nicht Lösungen auf, die er vielleicht gar nicht braucht oder sogar stören. Aber vielleicht etwas zu viel verlangt hier. I2C Module haben ja auch Pull Ups, verwendet man 3 Stück hat man 3x Pull Up's parallel und zwingt den STM in die Knie. Erst waren es 1 Mhz, dann 500Khz nachdem ich den APB1 auf 32 Mhz gesetzt habe, vorher war er 64 Mhz. Es funktioniert mit beiden nicht, die 100 khz denke ich machen den Kohl nicht fett. Die Karte initialisiert ja richtig bis sie auf SPI Betrieb ist, diese Routine läuft immer einwandfrei durch. Ansonsten auf 48Mhz SysClock und APB1 auf 24Mhz, dannn dürfte es passen. Aber jetzt ist das Board zerlegt. Ich baue das Ganze jetzt neu auf, nur die Pille und ein Adapter im Stecksockel, damit ich es tauschen kann. Habe diverse ohne Pegelwandler bestellt, wo ich den AMS117 totlegen werde für 3.3V Betrieb und schaue mir das dann mal genau an mit Oszi. Und wenn alles schiefgeht kommt ein openlog rein, der lässt sich ja auch etwas steuern, auch wenn er weniger Komfort hat.
Ok, nachdem alle Widerstände raus sind und die Bustakt auf ca 437 khz runter ist (28 Mhz Bus / 64) klappt alles bestens. Die Bits und Bytes schnubbeln nur so auf die Karte. Dem Ingeniör ist nichts zu schwör :-)
Stefan ⛄ F. schrieb: > Reicht dir das? 375 khz jetzt bei 48Mhz Coreclock und APB1 = 24 Mhz... damit bist Du auch sicher zufrieden :-))
Jetzt bin ich verwirrt, ich dachte die 437 kHz seien die SPI Taktfrequenz. Aber damit komme ich nicht auf 1.5MB / 8s.
Stefan ⛄ F. schrieb: > Acho so, ich dachte die 437 kHz seien die SPI Taktfrequenz. Nee, die MMC Spec verlangt die 400 khz für die Init Sequenz zur Umschaltung in den SPI Mode, erst danach kannst du aufs Gas treten. Ich werde versuchen die nächsten SD Anwendungen aber mit der SDIO zu machen,sofern ich dafür Code finde für den 411er. Ich schreibe grad jetzt, wo ich tippe mal 100MB auf die Karte. Zwei Kaffee reichen wohl nicht, ich werde noch ein Buch lesen gehen...
Du hast ja eine Homepage, ich einen YT Kanal.... denke mal ich werde das alles mal in ein Video packen, damit es nicht verloren geht. Denn da werden alle reinstolpern, die diese Adapter verwenden. Es gibt ja nur 5V Teile und diese 3.3V. Und die 5V haben alle Pegelwandler drauf. Wenn aber in Englisch, dann geht das leider nur mit "Teleprompter" flüssig.... also einiges an Arbeit. "GreatScott", ein Deutscher macht sich die, ebenso wie Andreas Spiess aber die verdienen auch richtig Geld damit.
Eine Sache noch, aber wichtig: Diese Sequenzen da unten müssen atomar sein, da sie wie ich grad merke zu einem Hängen führen, wenn da ein längerer Interrupt zwischen haut. SPI_I2S_SendData(SPI1,d); while (SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_RXNE) == RESET); Warum? Sobald das Bye im TX Register ist beginnt die Statemachine es raus zu schieben. Wenn alles raus ist wird das RXE Bit gesetzt. BSY braucht man nicht. Schiess der INT aber genau nach dem SendData dazwischen wird die nachfolgende Bedingung niemals == 0. Sie steht ggf schon auf 1, weil das Byte raus ist und dann steht die Anwendung still. Timeout ist da eher ungünstig, ich schalte die Ints da einfach jetzt ab.
habe gerade auch mal eine SD card an ein Bluepill angeschlossen, mit Mbed kein Problem. Ich vermute ich habe den gleichen SDC Adapter, der funktioniert auch mit den Pullups und losen Strippen. Das gleiche Programm läuft auf einem Blackpill mit F401 oder F411. Man kann auch das SDBlockDevice durch ein SPIFBlockDevice ersetzen und das Filesystem in ein SPI Flash legen (kann man auf die Blackpills auflöten). Für das SDIO vom F4/F7 habe ich auch ein Blockdevice gebaut, eine Zeile ändern und es wird SDIO benutzt. Das ist praktisch für die F407 China Boards, da ist ein SD Halter gleich mit drauf und an die SDIO Pins angeschlossen.
Johannes S. schrieb: > Ich vermute ich habe den gleichen SDC Adapter, der > funktioniert auch mit den Pullups und losen Strippen. Es funktioniert definitiv nicht (sicher) mit den R's. Und das ist auch anhand der MMC Spec eindeutig zu beweisen, die von Pull Ups von 100k spricht für die Leitungen, damit diese im Idle Mode nicht floaten. Und da sind 10k wirklich etwas sportlich. Man lese dazu mal Chan's Seite aufmerksam durch, denn der hat selbst jede Menge ausprobiert und seine Erfahrungen aufgeschrieben. Leider explodiert mit jeder Funktion die man nutzt auch die Codesize :-( f_sync extrem wichtig, damit man die FAT wegschreibt, alles was danach kommt ist bei Stromausfall zwar weg, Chan Buffert auch natürlich. Spielt alles einwandfrei und seit diese Hürde gefallen ist habe ich auch die ganze Filverwaltung schnell durchprogrammiert. 2 offene Files leider nicht, dann explodiert die Codesize noch erheblicher, liege schon bei 56kb bei -O3.. Debuggen kann ich aber leider nicht mehr, die Code Size liegt schon bei 68kb unoptimiert. Dafür halt Arduino Style, USART2 als Debug Interface.
Christian J. schrieb: > 56kb bei -O3.. Vielleicht ist es dir nicht bekannt, aber -Os ist die richtige Optimierung wenn es auf Size ankommt. -O3 eher für Speed aber da kann die Size dann auch schonmal wachsen.
:
Bearbeitet durch User
900ss D. schrieb: > Vielleicht ist es dir nicht bekannt, aber -Os ist die richtige > Optimierung wenn es auf Size ankommt. Das war ein Vertipper... O2 und Os ergeben fast das Gleiche, O3 bläst es auf, weil die Schleife aufgelöst werden. -Og ist für Debugging, leider werden TestVariablen aber weg optimiert. Sollte alles reissen wird der print_float weg optimiert... der kostet fast 8 kb... Aber Postbote war grad da.... jetzt wird alles gut :-)
W.S. schrieb: > Pille schrieb: >> Falsch! > > Kannst du lesen? Wenn ja, dann schau mal in das DB oder RM des > STM32F103C8T6 und du wirst dort lesen können, daß dieser eben 64K an > Flash hat. Punkt. Guten Morgen... Das was Du schreibst ist Richtig, hat aber mit dem was ich anmeckerte Nichts zu tun. Verstehendes Lesen ist heute wohl nicht Deine Stärke. Und wenn durch einen euch gnädigen Zufall da noch mehr > an Flash sein sollte, der sogar benutzbar ist und nicht vom Hersteller > abgeschaltet, dann darf man das eben NICHT erwarten bei einem Board, > was angeblich einen STM32F103C8T6 oder einen dazu kompatiblen Chip > enthält. Blah.. > > Irgendwie ist ohnehin dieser ganze Thread irrsinnig. Da wird gierig auf > Chips mit nem halben MB an Flash geschaut, immer "höher, schneller, > weiter und mehr Bässe" - und dann wird so ein Zeugs auf ein Steckbrett > gestopft und das ist dann das Ende der Fahnenstange. Unsereiner würde > stattdessen eine Projektentwicklung erwarten, wo am Ende ein Gerät > steht. Also etwas anderes als ein Drahthaufen auf'm Steckbrett. > > W.S. Irrsinnig bist wohl Du. Mein Falsch bezog sich auf die Behauptung das die meisten "Clones" 2 Chips enthalten würden, einen für den Prozessor, und einen für den Flash..und das ist falsch. Es gibt genau nur den GD32F103C8T6 bei dem das der Fall ist, der arbeitet den Code aus dem nach dem Booten im RAM ab, nachdem er aus einem seriellen Flash Chip im IC (!) in den RAM umgeladen wurde. Das ist nur bei einem einzigen dieser Clones der Fall, alle anderen haben den Flashrom auf dem Prozessor-Chip. ..und jetzt erkläre mir mal was Dein Gefasel oben mit dieser Tatsache zu tun hat. Pille
Stefan ⛄ F. schrieb: > Christian J. schrieb: >> Du kannst nicht eine Datenleitung auf der mit über 4 Mhz >> Datenlaufen mit einer LED belasten > > Dann muss ich wohl Geister gesehen haben, und zwar ziemlich viele. > >> Was kosten originooool Pillen und welcher Dealer verkauft den Stoff? >> Robotdyn hat sie ausverkauft. > > Neulich berichtete hier im Forum jemand, er habe originale bekommen. > Allerdings mit USB-C Buchse. Sie kosteten um 5 Euro. Ich glaube das war > bei Amazon (sagt nicht viel aus, ich weiß). Ich war das und es war nicht Amazon sondern Aliexpress, also einer der chinesischen Shops. Das war eine Plue Pill Version 2 bei der man beim Händler wählen konnte ob man einen CKS32 oder einen STM32 da drauf haben wollte. Der Händler beschrieb das er das Problem verstanden hatte.. https://de.aliexpress.com/item/4001116767437.html ..ist allerdings ausverkauft. Der hier bietet das Selbe an: https://de.aliexpress.com/item/32525208361.html "Always use original ST chips" Pille
Stefan, wollte keinen neuen Fred dafür aufmachen..... wieviele Backup Register hat die Pille und wie breit sind die? Was sind "20-Byte Data Register"? 20 x 8Bit? Das Handbuchn ist da etwas allgemein, weil die ja alle Typen drin verquickt haben. Hab grad Ärger mit diesen Dingern.... die resetten sich aus unbekannten Gründen. Leider vermute ich da auch Fehler in der StdPeriph Lib. In meiner CMSIS habe ich auch sch einen gefunden... GetITFlag und GetFlagStatus vertauscht worden.
da der x8/xB zu den medium density devices (siehe Datasheets) gehört, ist deine zitierte Seite doch eindeutig, 10x16 Bit.
Johannes S. schrieb: > da der x8/xB zu den medium density devices (siehe Datasheets) gehört, > ist deine zitierte Seite doch eindeutig, 10x16 Bit. Da steht 20-Byte... also so eindeutig ist das wohl nicht. 1 Byte = 8 Bit. Und Register sind keine Ram Zellen, die sind wohl nur als 16Bit ansprechbar. Und de StdPeripLibs, die von 2015 sind werden ja per define und tausend ifdef else eingestellt. Und da sind 42 Register ansprechbar, die aber nicht alle hintereinander liegen. Die auch im Debugger erscheinen, dessen .svd ich aus dem Netzt geklaut habe, die aber wohl alle Typen erschlägt. Ok, bleibt nur ausprobieren und debuggen....
Johannes, weisst Du auch zufällig ob man den Port GPIOC_13, wo die LED dran hängt missbrauchen kann, um den TAMPER Takt der RTC auszugeben? Ich wollte die mal mit meinem neuen Oszi kalibrieren. Und dazu spielt man ja den Takt raus und dreht am Kalibrierregister.
habe ich noch nicht gemacht, kann ich nur mit dem Finger auf Appnote 2604 zeigen, https://www.st.com/en/microcontrollers-microprocessors/stm32f103.html#documentation ist mit 14 Seiten überschaubar. Ich bin da ja von der faulen Sorte und sehe erst nach ob das OS das unterstützt, scheint nicht so. Dann in HAL nachsehen und in stm32f1xx_hal_rtc_ex.c findet man ein paar Tamper Funktionen, das geht vielleicht auch mit der SPL.
Hallo, klappt leider nicht, alles probiert. Aber was anderes: Ich habe alle meine BP getestet und die restlichen zusammen gelötet: Bei 4 Stück kommt beim Löschen: "Cannot Read. Please remove readout protection and retry." Natürlich lässt sich die nicht zurücksetzen, womit auch. BP's wegwerfen?
Ich glaube die "readout protection" protection kannst du mit dem ST-Link utility aus schalten. Ich hatte das auch einmal, ist aber lange her. Da haben sie dir offenbar gebrauchte Chips verkauft.
Sicher kann man die readout protection zurücksetzen, das führt nur logischerweise zum Löschen des gesamten Flash. Beschrieben zB hier: https://stackoverflow.com/questions/25770483/how-to-protect-reading-flash-of-stm32f10x Und das muss kein Bug oder gar gebrauchter Chip sein, eher ist da ein Arduino Bootloader drauf. Andere sehen das als Feature und bezahlen dafür sogar einen Aufpreis.
Beitrag #6655926 wurde von einem Moderator gelöscht.
Prima, hat geklappt. Hatte ich wohl übersehen, dass da die Option Bytes gesetzt werden können. War auch was drauf, die Blinky Appist wohl überall drauf. Bin übrigens mit dem OPwon SDS1102 voll zufrieden! Wobei ich den Eindruck habe dass das für 165 Euro wohl vom Laster in China gefallen ist. Kam jedenfalls problemlos durch den Zoll durch und direkt an. Schönes Teilchen!
Sag mal einer, wie kriegt man unter EmBitz die BlackPill 401 ans Debuggen? Bisher steht da alles still, es wird nichts geflashed. Welchen Controller muss man denn da einstellen bei der Projekterstellung? Da sind ja einige 401er aber der auf dem Board ist nicht dabei. Da steht 401CEU6 drauf. Das Flashen des Release mit St-Link klappt aber problemlos. Nur eben nicht über den Debug Server. Nur die RE Version hat die erkannten 512KB Flash. /*---------------------------------------------------------------------- -------- * Linker script for running in internal FLASH on the STM32F401RE *----------------------------------------------------------------------- -----*/ OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm") OUTPUT_ARCH(arm) SEARCH_DIR(.) /* Memory Spaces Definitions */ MEMORY { ROM (rx) : ORIGIN = 0x08000000, LENGTH = 512K RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 96K }
Und die Fehlermeldungen von STlinkGDB ? Also wenn der Autor schon schreibt ‚forget STLinkGDB‘... https://www.embitz.org/forum/thread-25.html
Beitrag #6666411 wurde von einem Moderator gelöscht.
Johannes S. schrieb: > Und die Fehlermeldungen von STlinkGDB ? Also wenn der Autor schon > schreibt ‚forget STLinkGDB‘... > https://www.embitz.org/forum/thread-25.html Lass Dich abknutschen! EBLInk endlich zum Laufen gebracht, weil das da alles etwas chaotisch beschrieben ist. Er ersetzt den ST Link und man muss keine neue Rubrik anlegen. Jedenfalls wird der 401er geflascht, wenn auch falsch als 411er erkannt... und was noch besser ist: Mein Bluepill Projekt hat endlich 128 kb ! Einige der Pillen haben diese ja, ca 2/3 bei mir und wie ich grad sehe wurden 78kb gebrannt und verified. Und weiter gehts mit dem Code, da fallen mir doch glatt noch ein paa Features ein, die ich dringend brauche... Wozu float wenn auch für double Platz ist? :-)
Christian J. schrieb: > Bisher steht da alles still, es wird nichts geflashed. Welchen > Controller muss man denn da einstellen bei der Projekterstellung? Da > sind ja einige 401er aber der auf dem Board ist nicht dabei. Da steht > 401CEU6 drauf. Ich habe STM32F401RE in EmBitz ausgewählt, anschließend eine Datei stm32f401ce_flash.ld mit den korrekten Daten für RAM und ROM erzeugt und damit die stm32f401re_flash.ld ersetzt - siehe Anhang. Anschließend habe ich unter "Build Options" -> "Device" -> Linker Script den Eintrag von "./stm32f401re_flash.ld" nach "./stm32f401ce_flash.ld" geändert. Ich habe neben den STM32F401CE auch noch die CC Ausführung, siehe 2. Anhang. Zur Frage Debugging: Seitdem ich Win10 statt Win7 einsetze, klappt das bei mir nicht mehr. Irgendein USB-Problem. Das hatten damals auch noch viele andere EmBitz-User, die meldeten sich dort alle im Forum. Eine richtige Lösung wurde nicht gefunden. Das alte Forum ist wegen des damaligen Crashs von embitz.org aber schon vor einigen Monaten verlorengegangen. Mittlerweile gibt es aber auf der neuen (noch sehr knapp gehaltenen) EmBitz-Seite EBLink zum Debuggen. Habe ich aber noch nicht ausprobiert. P.S. Zu den Anhängen: Keine Gewähr, ich habe damit bereits jeweils ein Projekt erfolgreich kompiliert, aber das Compilat noch nicht auf den 401-Pills getestet.
:
Bearbeitet durch Moderator
Frank M. schrieb: > Ich habe STM32F401RE in EmBitz ausgewählt, anschließend eine Datei > stm32f401ce_flash.ld mit den korrekten Daten für RAM und ROM erzeugt und > damit die stm32f401re_flash.ld ersetzt - siehe Anhang. Das habe ich auch schon gemacht inzwischen, danke aber trotzdem. Unter Win7 läuft das alles noch. Hab nur gerade die veralteteten SPL Libs von 2011 gegen die 2013 ausgetauscht, die 2011er hatte Bugs drin. Aktuell weiss ich nicht wie man EBlink diese zeile mitgeben kann: eblink.exe -I stlink -S auto -P ../scripts/ -G trägt man die in Extra Options ein läuft es wieder nicht mehr. Denn Debuggen klappt, das mit dem Release flashen leider nicht. Denn da steht immer noch der st-link und eblink blinkt nur kurz auf und ist dann weg weil ich seine Parameterliste noch nicht kenne.
Ok, ich habs, zumindest klappt es. Ob da noch was hin muss... naja. Flashing Release: -I stlink,dr,speed=1800 -F erase,verify,run,file="${TARGET_OUTPUT_DIR}${TARGET_OUTPUT_BASENAME}.hex " Pustekuchen.... 128kb Flash.... brenne ich eine Testdatei bricht er nach ca 80kB ab mit einem Verify Fehler.... wäre ja auch zu schön gewesen, das Doppelte für den gleichen Preis zu kriegen. edit: bei ner anderen Pille klappt es mit 128kb aber ich hoffe mal dass die Bits nicht nach kurzer Zeit vom Winde verweht sind...
Frank M. schrieb: > Ich habe STM32F401RE in EmBitz ausgewählt, anschließend eine Datei > stm32f401ce_flash.ld mit den korrekten Daten für RAM und ROM erzeugt und > damit die stm32f401re_flash.ld ersetzt - siehe Anhang. Hast Du ndafür auch eine Lösung gefunden? Kommt nämlich bevor er nach ain reinläuft als Runtime Fehler. Die RAM Size ist übrigens 96KB bei der CE Version. Nicht 128kb Vielelicht hast du ja mal auch deinen startup Code? Hier hängt er sich auf: #ifndef __NO_SYSTEM_INIT ldr r0, =SystemInit blx r0 #endif Ich habe den hier, stammt wohl aus dem Attolic Studio Da stimmt sowieso einiges nicht, SystemInit will auf 168 Mhz einstellen, der kann aber nur 84 MHz. usw. Den Code habe ich damals bei dem Discovery Board STM32F407 verwendet, der schnurrte auf 168. Die 407er kamen aber wohl danach auf den Markt. /* File: startup_ARMCM4.S * Purpose: startup file for Cortex-M4 devices. Should use with * GCC for ARM Embedded Processors * Version: V1.3 * Date: 08 Feb 2012 * * Copyright (c) 2012, ARM Limited * All rights reserved. *
Christian J. schrieb: > Vielelicht hast du ja mal auch deinen startup Code? Ich verwende ein von mir angepasstes system_stm32f4xx.c, das auf allen STM32-Boards, die ich derzeit verwende, läuft, siehe Anhang. Gesteuert wird das durch Angabe von -DSTM32F4nn und HSE_VALUE. Wie gesagt, ist für die 4XX-Pills noch ungetestet, sollte aber funktionieren, da ich die Werte mittels STM-CubeMX ermittelt habe. Für die 401-Pill mit 25MHz-Quarz ist in den Projekt-Optionen einzustellen:
1 | -DSTM32F401 |
2 | -DHSE_VALUE=25000000 |
Resultat: Clock 84MHz. Für die 411-Pill mit 25MHz Quarz:
1 | -DSTM32F411 |
2 | -DHSE_VALUE=25000000 |
Resultat: Clock 100MHz. Für STM32F401 Nucleo-Boards (8MHz Quarz):
1 | -DSTM32F401 |
2 | -DHSE_VALUE=8000000 |
Resultat: 84MHz. Für STM32F411 Nucleo-Boards (8MHz Quarz):
1 | -DSTM32F411 |
2 | -DHSE_VALUE=8000000 |
Resultat: 100MHz. Für STM32F407VE Black-Board und STM32F407VG Discovery Board (8MHz):
1 | -DSTM32F407 |
2 | -DHSE_VALUE=8000000 |
Resultat: 168MHz. Die resultierenden Werte wie Clock-Div/Multiplier und auch Wait-States (wichtig!) werden darüber automatisch ermittelt. Siehe auch Kommentare in system_stm32f4xx.c
:
Bearbeitet durch Moderator
Frank M. schrieb: > system_stm32f4xx.c Moment kurz... das ist aber nicht der Startup Code. Der ist eine ASM Sequenz. Die Datei die du gepostet hast muss angepsst werden abe die liegt noch über dem CMSIS Layer. Ich meine den ganz unten. den .s ASM der vom GCC als Befehl Nr. 0 angefangen wird. Ich wehre mich noch verzweifelt gegen HAL und CubeMX aber leider wird der Widerstand wohl zweckloser.... die SPL ist komplett veraltet :-(
Frank M. schrieb: > Resultierende Werte wie Clock-Div/Multiplier und auch Wait-States werden > darüber automatisch ermittelt. Da bin ich mir noch nicht so sicher. Bei meiner Datei der SPL sind da Tabellen hinterlegt für die MUL DIV Werte. Der F401 passt nicht den den alten M4 Sourcen, die setzen pauschal 168 Mhz für 407 und 417 an. Der 401 und der 411 spielen die Musik aber mit 84 BPM ab.
Christian J. schrieb: > Moment kurz... das ist aber nicht der Startup Code Du hattest über falsche Clocks gesprochen, die stehen nicht im Startup-Code, sondern in der oben geposteten C-Datei. Die ASM-Datei startup_stm32f4xx.S wird von EmBitz automatisch beim Anlegen des Projekts erzeugt und ist für alle STM32F4XX gleich. Die muss man nicht anpassen. Zu Beginn in main () starte ich immer als erstes:
1 | SystemInit (); |
2 | SystemCoreClockUpdate (); |
Dann passt das.
Frank M. schrieb: > Christian J. schrieb: >> Moment kurz... das ist aber nicht der Startup Code > > Du hattest über falsche Clocks gesprochen, die stehen nicht im > Startup-Code, sondern in der oben geposteten C-Datei. > > Die ASM-Datei startup_stm32f4xx.S wird von EmBitz automatisch beim > Anlegen des Projekts erzeugt und ist für alle STM32F4XX gleich. Die muss > man nicht anpassen. > > Zu Beginn in main () starte ich immer als erstes: SystemInit (); > SystemCoreClockUpdate (); > > Dann passt das. Fank, Du hast meinen Post gelesen, oder? Sonst hat das jetzt echt keinen Zweck. Nicht böse gemeint.... aber die .s passt eben nicht. Defintiv nicht.
Christian J. schrieb: > Da bin ich mir noch nicht so sicher. Bei meiner Datei der SPL sind da > Tabellen hinterlegt für die MUL DIV Werte. Der F401 passt nicht den den > alten M4 Sourcen, die setzen pauschal 168 Mhz für 407 und 417 an. > Der 401 und der 411 spielen die Musik aber mit 84 BPM ab. Das ist alles berücksichtigt, schau doch erstmal rein, bevor Du hier reflexartig antwortest. Die 401er werden auf 84MHz getrimmt, die 411er auf 100MHz, die 407er auf 168MHz. Bitte erst lesen, dann schreiben. ;-)
Frank M. schrieb: > Bitte erst lesen, dann schreiben. ;-) Das gebe ich jetzt man so zurück :-) Da sind Bilder dran.... dingelingeling :-) Läuft defintiv nicht, weder mit EBlink, noch mit dem ST-Link... der kommt nicht mal in die Nähe der Main(). Bei mir jednfalls nicht. Habe dafür neuen Fred aufgemacht, da hier OT.
Christian J. schrieb: > Fank, Du hast meinen Post gelesen, oder? Sonst hat das jetzt echt keinen > Zweck. Nicht böse gemeint.... aber die .s passt eben nicht. Defintiv > nicht. Bei mir passt das, siehe Projekte STECCY, IRMP, WordClock mit WS2812 und MCURSES. Die arbeiten *alle einheitlich* mit ein- und derselben Startup-Datei und auch mit oben genannter C-Datei system_stm32f4xx.c. Und die funktionieren mit STM32F401, STM32F411 und STM32F407. Wenn das bei Dir nicht passt, machst Du irgendetwas systematisch verkehrt.
:
Bearbeitet durch Moderator
Kann sein... auch wenn ich jede Schraube bald kenne, man lernt nie aus. Kannst du trotzdem mal die .s Datei hier dran pflastern? Und den RAM hast du auch falsch eingetragen bei der .ld Datei. Sind 96kb nicht 128 kb bei der CE Version. Die 401/411 lassen sich mit st-link gdb nicht bespielen. Hast Du Eblink oder was anderes? Welche Parameter hat der und wo hast du die eingetragen. Kann ja schon daran liegen. Bei mir nimmt der die gar nicht an und ich habe die EBlink Scripte alle mit drin, die IDE zeigt mir eine neue GUI an. mach doch mal Snapschots von Debug Interface, allen Fenstern dort. Und die Projekt Einstellungen. Debug RAM nutze ich nicht, wäre aber auch mal nett zu testen.
Christian J. schrieb: > Und den RAM hast du auch falsch eingetragen bei der .ld Datei. Sind > 96kb nicht 128 kb bei der CE Version. Ja, habe ich gelesen und zur Kenntnis genommen: Ich schrieb ja, dass die LD-Dateien speziell für 401CC und 401CE noch ungetestet sind. Jedoch laufen die Clock-Einstellungen in system_stm32f4xx.c schon seit Jahren perfekt. Und da ist es egal, ob das ein 401RE oder 401CE ist. Anbei das Standard-Startup-File aus EmBitz.
Frank M. schrieb: > nbei das Standard-Startup-File aus EmBitz. 1:1 identisch. Tja, wieso es bei mir abstürzt ist dann wohl ... ich weiss es noch nicht. Da habe ich keine Ahnung, da mir das zu tief rein geht. Solange die Tooplchain nicht steht ist da alles vergeblich.
Christian J. schrieb: > Die 401/411 lassen sich mit st-link gdb nicht bespielen. Hast Du Eblink > oder was anderes? Ich schrieb doch gestern, dass ich seit der Umstellung von Win7 auf Win10 nicht mehr debuggen kann wegen eines USB-Problems. Bitte oben nochmal nachlesen, damit ich nicht immer alles doppelt schreiben muss.
Christian J. schrieb: > Tja, wieso es bei mir abstürzt ist dann wohl ... ich weiss es noch > nicht. Vielleicht, weil Deine Clock-Settings und Wait-States nicht stimmen? Ersetze doch einfach die Datei system_stm32f4xx.c mit meiner, füge die beiden Preprozessor-Konstanten STM32F01 und HSE_VALUE zu Deinen Projekt-Settings hinzu und probiere das aus. Das ist doch nicht so schwierig. Ich mache das schon seit Jahren so. Ich teste das am Wochenende mal mit meiner 401er Pill. Ist bei Deinem Board ein 8MHz- oder 25MHz-Quarz? Bisher habe ich nur 25er Boards gesehen.
:
Bearbeitet durch Moderator
Frank M. schrieb: > Vielleicht, weil Deine Clock-Settings und Wait-States nicht stimmen? Die .s wird abgearbeitet im Default Mode, d.h. 25 Mhz mit allen WS auf 0, wie im Datenblatt beschrieben. Erst die RCC .c gibt dann Gas und stellt sie ein. Mein problem hat damit also nichts zu tun, der Startup weiss von allem noch nichts. Es ist ein 25Mhz Quarz drauf, wie bei allen wohl. Ich arbeite das heute nachmittag aber mal ein und schaue was passiert. Vor allem die PreProz Konstanten dürften Wirkung zeigen, da sie ja schon den Code erzeugen, der ausgeführt wird.
Frank M. schrieb: > Ich schrieb doch gestern, dass ich seit der Umstellung von Win7 auf > Win10 nicht mehr debuggen kann wegen eines USB-Problems. Ist nur so ein Rat: Das und auch weil ein gekauftes Videoschnittprogramm für 500 Euro mit Win10 nicht kompatibel ist läuft bei mir Win7 bis sie es per Fernsteuerung abschalten. Es gibt bis Dato kein Programm was ich privat brauche, was Win10 erfordert, da ich den ganzen Kachel Quatsch nicht mitmache. Mein Medion Netbook (64GB Flash, 4 GB RAM, Dual Core) war mit Win10 eine Schnecke geworden, daher wieder Linux drauf, auch wenn ich da den Touchscreen verloren habe.
Christian J. schrieb: > Erst die RCC .c gibt dann Gas und > stellt sie ein. die stm32f4xx_rcc.c ist allgemeiner Code, die system_stm32f4xx.c enthält die spezifischen Einstellungen, und die von Frank sieht gut aus. Die ist auch von HAL/SPL unabhängig weil das noch in CMSIS definiert ist.
Johannes S. schrieb: > die stm32f4xx_rcc.c ist allgemeiner Code, die system_stm32f4xx.c enthält > die spezifischen Einstellungen, und die von Frank sieht gut aus. Die ist > auch von HAL/SPL unabhängig weil das noch in CMSIS definiert ist. Sobald ich heute abend meinen kaffee, ne neue Packung Fluppen und Ruhe habe setze ich mich mal dran. Eines nach dem anderen. 401RE Projekt erzeugen. Linker File anpassen Defines eintragen in PreProzessor system_stm32f4xx.c einspielen wenn es läuft die alte 2011 SPL gegen die 2013er tauschen, die leider Fehler erzeugt, da auch die CMSIS angepasst werden muss. Einfach drüber kopieren erzeugt jedenfalls so viele Fehler wie man nicht mehr zählen kann. Und da sind nichts rückgängig machen lässt immer schön Kopien sichern :-)
Christian J. schrieb: > Und da sind nichts rückgängig machen lässt immer schön Kopien > sichern :-) oh je.... 'git init', alles andere ist Chaos aus dem letzten Jahrhundert. Ach ja, EmBitz... passt :)
Beitrag #6667052 wurde von einem Moderator gelöscht.
Tja, da staunt der Laie und der Fachmann wundert sich! DAS SCHEISSDING GÄÄÄÄÄÄHT! ES GÄÄÄÄHT! Nachdem ich das eingebaut habe, dabei noch die CMSIS auf die 2015er Version gebracht habe und die alte 2011er SPL auf die 2015er gebracht. Nur leider... es sind auch Funktionen erreichbar, die es defintiv nicht gibt. Ich habe mal Code vom 407er einkopiert, der 4KB Backup Ram hat. Altes Discovery Projekt mit einer Wetterstation. Läuft durch... dabei hat der 401er gar kein Backup Ram. Die Defines habe ich dem GCC mitgegeben... denke mal der Linker kann damit wenig anfangen. 512kb Flash.... wie soll ich die bloss jemals vollkriegen? uGfX Grafikoberfläche vielleicht oder nen RTOS Unterbau? Da kommen ja ganz neu Möglichkeiten in Betracht ;-) die 4er sind einfach geile Maschinchen! Aber ein F103er Projekt portieren mit 12 Modulen....nee, das tue ich mir nicht an, dafür sind die 4er zu unterschiedlich.
Frank M. schrieb: > Mit meiner system_stm32f4xx.c? Tjoooo! Aber ist das D vor den Defines echt richtig? Ich habe die immer so rein geschrieben.
Christian J. schrieb: > Aber ist das D vor den Defines echt richtig? Unter "C-Flags": Ja, das muss so sein. Die Compiler-Option -D bedeutet: Es folgt unmittelbar ein Define. -DXXX ist das gleiche wie im C-Quelltext:
1 | #define XXX
|
-DXXX=nnnn ist das gleiche wie im C-Quelltext
1 | #define XXX nnnn
|
Der Vorteil in den Build-Options ist, dass dieses define für alle C-Module gilt. Sonst müsste man das ja jede Datei schreiben. P.S. Unter dem Reiter "#defines" wäre das dann ohne -D, dann stellt die IDE dann selbst das "-D" voran. Du kannst also STM32F401 und HSE_VALUE auch unter "#defines" platzieren, dann ohne "-D" davor. Warum hast Du da STM32F401CB und STM32F401RE definiert? Nur eines kann richtig sein.
:
Bearbeitet durch Moderator
Ich habe es grad getestet, bei Embitz reicht es wenn man es ohne D in die Defines schreibt. Dann baut er es davor. Ok, erstmal aus anderen projekten Code klauen und ein Basisgerüst bauen und das dann auf einem Stick sicher verwahren. Ich danke Dir ganz herzlich erstmal!
Christian J. schrieb: > Ich habe es grad getestet, bei Embitz reicht es wenn man es ohne D in > die Defines schreibt. Jepp: Unter Options mit "-D", unter "#defines" ohne "-D".
So, Fenster zu, Sonnenschein draußen lassen, heute nacht ist eh Ausgangssperre... und ich schätze mal ich werde erst morgen mittag wieder aufstehen, weil das ne längere Nachtsitzung werden könnte :-) Die Faszination uC seit 1986 (8085 und Z80, 8051) lässt nie nach.... Werde da ggf vllt später mal verarbeiten: https://www.youtube.com/watch?v=zmPWeF2OhoU
Frank, leider habe ich viel Ärger mit "Connection to target lost" und dann muss ich die Pills wieder mit ST-Link löschen und dabei Boot und NRST drücken. Da stimmt nochwas nicht..... an er Speed liegt es jedenfalls nicht. Sobald ich RUN tippe.
Frank, hast Du zufällig ein gültiges .svd File für den Debugger? Meines ist aus welchen Gründen auch immer ungültig.
Frank M. schrieb: > Jepp: Unter Options mit "-D", unter "#defines" ohne "-D". Moin, könnte vielleicht mal jemand bei seinen blauen Pillen den STOP Mode testen? Bei mir funktioniert der nicht. Das Teil schläft ein aber wacht nicht mehr auf, wenn der Int Pin (PA1) einen Flanken-INT auslöst. Den per RTC aufwachen lasen wäre nicht Sinn der Sache.
Frank M. schrieb: > Ich schrieb doch gestern, dass ich seit der Umstellung von Win7 auf > Win10 nicht mehr debuggen kann wegen eines USB-Problems. Bitte oben > nochmal nachlesen, damit ich nicht immer alles doppelt schreiben muss. Hi, I was pointed by someone to this discussion and the complains that EBlink wouldn't run in windows 10. We, project team of 12, are all working with EBlink in windows 10 without any problems whatsoever. Also as remote debugger with remote desktop and various win10 releases. We are using currently the standard STmicro device driver (Grenoble) 2.1.0.0. In the past we had a lot of problems with composite USB devices (ST-link/mass-storage etc) and older libUsb releases but since EBlink we never had such problems again. I would like to have some feedback about the driver/win releases with the problems. Thanks, Gerard P.s. Also the windows shell context menu application works nicely in both win7 (32/64) and windows 10.
Gerard Z. schrieb: > We, project team of 12, are all working with EBlink in windows 10 > without any problems whatsoever. Hi, I use EBlink on my cheap W10 Netbook with Embitz 1.11 and China-StLink V2 and have no problems. The only problem I have is that I have to remove USB for a second when switching from Debug to Release. Same problem as with st-link GDP server but I can live with this. Context Menu's? `I dont know what to do with them... where can I find a description? And how can I tell EBlink to take over the parameter list from embitz Debug? e.g. speed It's ignored from the extra fields in the Debug / Server / Additional Setting section :-(
Gerard Z. schrieb: > Frank M. schrieb: > >> Ich schrieb doch gestern, dass ich seit der Umstellung von Win7 auf >> Win10 nicht mehr debuggen kann wegen eines USB-Problems. Bitte oben >> nochmal nachlesen, damit ich nicht immer alles doppelt schreiben muss. > > Hi, > I was pointed by someone to this discussion and the complains that > EBlink wouldn't run in windows 10. That is a misunderstanding. I only wrote that I can no longer debug since the change from Windows 7 to Windows 10. What I meant was debugging with ST-Link on Nucleo boards using the offical debugging method supported in EmBitz 1.11 - not EBlink.. > In the past we had a lot of problems with composite USB devices > (ST-link/mass-storage etc) and older libUsb releases Yes, that's exactly what I meant. But I will try EBlink in the near future. Actually, I wanted to wait for Embitz 2.0, but I assume that this version will never be released. I understand the word "soon" to mean something other than several years ;-) Are the updates for EmBitz 1.11 from user "Mink" in the Embitz forum official updates? P.S. On embitz.org there is a link with the name "EmBitz 1.10" at the very bottom of the page, but it is actually version 1.11. P.P.S. I would appreciate it if before the release of EmBitz 2.0 a version EmBitz 1.12 would be released with the following points: - EmBitz version 1.11 - Updates from the user Mink - EBLink support as standard If we have to wait even longer for version 2.0, you will run out of users.
:
Bearbeitet durch Moderator
Frank M. schrieb: > If we have to wait even longer for version 2.0, you will run out of > users. ...zudem Segger seit Langem mit dem Studio ein sorglos Paket anbietet, wenn man dazu noch die EDU Hardware kauft. Allerdings nur für amtliche Chips, die Klone und Derivate aus dem Reich mit Weltherrschaftsansprüchen werden damit nicht erkannt. Was eblink komplett ignoriert, der nimmt alles was den Steckern ist.
Frank M. schrieb: > If we have to wait even longer for version 2.0, you will run out of > users. Well, if that would cost me revenues then that would be a bad thing but the opposite is true I'm afraid :) I had already the feeling a couple of years back, that EB was losing its significancy because of the many free IDE's that came available in those days. Also the number of critics started to out number the positive feedbacks on the forums. But I'm still surprised every day how many downloads there are even on that bare minimum EmBitz web site. The last couple of years I'm very busy, I'm working freelance, with all kind of projects which limited my time to work on EB. I'm still maintaining it because it's my daily workhorse IDE and if I find something strange I solve it right away and same with features. That's also why I started EBlink, I needed a solution to work with my projects. If I need to work on an Atmel, I add Atmel. If I need additional breakpoints, I will add flash breakpoints... and so on. The IoT project I'm currently working on was planned for just a couple of months but it did grow bigger and bigger. EB 2.0 is almost finished to be published and also the old EmBitz web site is recovered and only needs a cleanup but I have to prioritize my customers projects, I have to keep the chimney smoking ( I think that's dutch) @Christian J. Eblink has also a windows installer. It will not only install (and configure) EBlink but it also installs an additional windows shell context menu handler. This menu handler will add an EBlink submenu to the standard windows right click menu so that you can easily flash a .elf, hex or srec file or e.g. start/stop GDB server. See attached picture. EBlink is a 32 bits application and in the windows installer is both a 32 and 64 bits shell context application and runs on older windows versions upto win10. The installer also configures some environment variables for default EBlink parameters which are used if they are missing from the CLI. So if a command shell is opened in any directory you can just invoke EBlink as e.g. EBlink -g or EBlink -f dump=1024@0x08000000:myDump.hex Download: https://www.embitz.org/
Christian J. schrieb: > > ...zudem Segger seit Langem mit dem Studio ein sorglos Paket anbietet, > wenn man dazu noch die EDU Hardware kauft. Allerdings nur für amtliche > Chips, die Klone und Derivate aus dem Reich mit > Weltherrschaftsansprüchen werden damit nicht erkannt. Was eblink > komplett ignoriert, der nimmt alles was den Steckern ist. Perhaps I'm a competitor to them (which I also doubt) but they are not for me, if you get what I mean.
Gerard Z. schrieb: > Perhaps I'm a competitor to them (which I also doubt) but they are not > for me, if you get what I mean. No, not a competitor.... we use Segger here in our Development Department and Production Unit because it is a certified tool with support and regular updates. I use Embitz for more than 5 years now (only hobby) and I am very happy with it. Sometimes i crashes but not very often. Not for Arduino and AVR but for everything with STM32 and NXP.
Gerard Z. schrieb: > EB 2.0 is almost finished to be published OK, then I'll wait with EBLink until EB 2.0 is released. ;-)
Frank M. schrieb: > OK, then I'll wait with EBLink until EB 2.0 is released. ;-) 2021? 2022? Bricht dann der Download Server genauso zusammen wie die Corona Hotlines hier bei Beginn der Impfungen ? :-))))
If there was a free and fast non java alternative (preferable portable) with at least live variables/expressions, decent SVD viewer and custom debugger plugins for specific OS debugging which don't lock me to dedicated hardware then I would probably abandon EB.
Gerard Z. schrieb: > I would probably abandon EB I think EB is the best IDE for STM32. It works very fast even on older PCs, is clearly laid out, very configurable and also allows you to specify several targets for one and the same project. Abandoning EB is therefore not an option ;-)
Frank M. schrieb: > Abandoning EB is therefore not an option ;-) Das sieht aber leider so aus :-( Ich würde auch was drum geben, wenn das kein Lost Place würde..... ist ja schon megageil, dass fast jedes BP Board jetzt 128kb hat, seit openocd durch EBlink ersetzt wurde (was sich auch noch prima über die cmd bedienen lässt). Nur ganz wenige überstanden den 128kb Test nicht.
Christian J. schrieb: > Das sieht aber leider so aus :-( That's the current 1.11 branch on the public server and is no longer maintained. As soon as 2.0 will become public those sources must also be made public.
Gerard Z. schrieb: > That's the current 1.11 branch on the public server and is no longer > maintained. As soon as 2.0 will become public those sources must also be > made public. Ok, Mr. "Embitz"... we grab the blue pill and keep on waiting with wet hands for the 2.0 version.... this summer in your local cinema :-)
Frank M. schrieb: > I would appreciate it if before the release of EmBitz 2.0 a version > EmBitz 1.12 would be released with the following points: > > - EmBitz version 1.11 > - Updates from the user Mink > - EBLink support as standard It is easy to do it. https://www.dropbox.com/s/szltjhs1vjo9n6e/EmBitz_1.12.exe This is an unofficial release. I hope Gerarard will not mind.
Guest schrieb: > This is an unofficial release. Ver. 1.12 Build Dec 2016 ??? Besides STM32 and ESP32 support for eblink i dont see any changes, compared with 1.11. Just replaced the GCC 5.2020. Works fine, smaller code, some additional warnings appeared.
Ja, so geht das wenn man mal eben was erneuern wird.... die Link Time Optimization bei 1.12 klappt nicht mehr, der Code ist nicht mehr lauffähig. Also alles wieder downgraden. Das sind immerhin -20kb auf 80kb.
Christian J. schrieb: > Ver. 1.12 Build Dec 2016 ??? Because it's 1.11, which has a modified version in the HEX editor. It was done that was asked. Frank M. schrieb: > I would appreciate it if before the release of EmBitz 2.0 a version > EmBitz 1.12 would be released with the following points: > > - EmBitz version 1.11 > - Updates from the user Mink > - EBLink support as standard ---------------------- Christian J. schrieb: > Optimization bei 1.12 klappt nicht mehr, der Code ist nicht mehr > lauffähig. Have you chosen a Release target?
Christian J. schrieb: > die Link Time Optimization bei 1.12 klappt nicht mehr, der Code ist > nicht mehr lauffähig. LTO for STM32 is broken in newer gcc-arm-none-eabi releases.
Frank M. schrieb: > LTO for STM32 is broken in newer gcc-arm-none-eabi releases. gcc-arm-none-eabi 9 great support for LTO. See if there is a check "Use Link Time Optimization" on the Linker tab for target Release.
Frank M. schrieb: > But I will try EBlink in the near future. Actually, I wanted to wait for > Embitz 2.0, but I assume that this version will never be released. I > understand the word "soon" to mean something other than several years > ;-) > > Are the updates for EmBitz 1.11 from user "Mink" in the Embitz forum > official updates? > > P.S. > > On embitz.org there is a link with the name "EmBitz 1.10" at the very > bottom of the page, but it is actually version 1.11. > > P.P.S. > > I would appreciate it if before the release of EmBitz 2.0 a version > EmBitz 1.12 would be released with the following points: > > - EmBitz version 1.11 > - Updates from the user Mink > - EBLink support as standard > > If we have to wait even longer for version 2.0, you will run out of > users. @Frank Well, is was a tough birth but 2.0 is there. It ticks your list: - Mink's updates in the wizard - EBlink is tightly integrated The integration of EBlink went very well, if I may say so myself. It makes very fast debug sessions possible because unnecessary closure of EBlink is avoided as much as possible so we don't have to fill the flash cache again and again between sessions. EBmonitor was sometimes going crazy on debugger stop in 1.11 and that is solved by redesigning that plugin. Another novelty is the Hot plug (F6) menu option. This will launch your debugger and connect to the target without resetting or stopping. So your previous debug session is restored and all the live variable/expressions are available to inspect your target without intervention after e.g. a day running. There is also a Flash menu item which can chip erase your device, flash a target or dump device memory to file. Also a lot of bug fixes and the toolchain is now standard Launchpad 9.3. The project file is not one-on-one compatible with 1.11 and you need some tweaking in the compiler/linker and debug settings. I decided to release it without a 1.11 importer because 2.0 would not survive the labor pain :)
Johannes S. schrieb: > habe gerade auch mal eine SD card an ein Bluepill angeschlossen, Was ist das schwarze zylindrische Modul? Ist das ein Absolutwertdrehgeber?
:
Bearbeitet durch User
Walter T. schrieb: > Was ist das schwarze zylindrische Modul? Ist das ein > Absolutwertdrehgeber? Ein Inkrementalgeber, ein guter von Grayhill. Wie im iDrive von BMW, also drehen, drücken und Taster für oben/unten/rechts/links.
Johannes S. schrieb: > Walter T. schrieb: >> Was ist das schwarze zylindrische Modul? Ist das ein >> Absolutwertdrehgeber? > > Ein Inkrementalgeber, ein guter von Grayhill. Wie im iDrive von BMW, > also drehen, drücken und Taster für oben/unten/rechts/links. Soetwas wie die 60A-Serie? Gut zu wissen, dass es soetwas einzeln zu kaufen gibt, auch wenn der Preis für viele Anwendungen abschreckend ist. Danke für die Antwort!
:
Bearbeitet durch User
ja, genau ein 60A18-4-020C. Der Preis ist wirklich happig, sollte mal für einen CarPC sein. Habe dann aber gleich einen fertigen CarPC mit BMW gekauft :)
EmBitz schrieb: > @Frank > Well, is was a tough birth but 2.0 is there. Congratulations! > It ticks your list: > > - Mink's updates in the wizard > - EBlink is tightly integrated Thank you very much, I read it in the following thread Beitrag "EMbitz IDE lebt? Kommt bald neue Version 2.0!" a few days before. > The integration of EBlink went very well, if I may say so myself. I tested EBlink a few weeks ago and had to conclude: - Debugging with China ST-Link works - Debugging with original STM32 Nucleo board (ST-Link on board) does not work. I will now install EmBitz 2.0 and also test EBlink again with the Nucleo board. It is probably better to discuss EMBITZ 2.0 in the future in thread Beitrag "EMbitz IDE lebt? Kommt bald neue Version 2.0!" . Therefore I will cross-post my post there.
:
Bearbeitet durch Moderator
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.