N'Abend, stunden bzw Tage dachte ich, ich wäre bloss zu doof zum Programmieren. Habe dann mal alle Pillen aus den letzten beiden Jahren zusammen gelötet und in die Anwendung gesteckt (81kb Code). Die Anwendung nutzt fast alle Hardware: 4 Timer, I2C für 3 Devices, SPI, Sleep, Stop Mode, ADC per DMA, RTC usw. usw. Erfreulich: Alle Boards lassen 80kb und mehr zu, volle 128kb also. Grosser Mist: Die Hälfte der Boards sind defekt! Software kann nicht mal laufen und mal nicht, wenn die Hardware die Gleiche ist, geht oder geht nicht. Defekt sind: Hardware I2C Bus hängt sich auf, Board startet gar nicht erst. Stop Mode wird nie wieder verlassen mit Wake Pin. RTC springt nicht an (WaitForSynchro hängt sich auf) Die mit den roten Punkten fliegen jetzt in die Tonne, auch wenn Teile davon vielleicht funktionieren. Wie sind da eure Erfahrungen?
Angehängte Dateien:
BluePill sind tot, weil dreiste Chinesen irgendwelche gefälschten Chips drauflöten Beitrag "STM32F103C8T6 - Fälschung von ST bestätigt" Es gibt da einige Replikas, wie HK32F103, CKS32F103, GD32F103 oder APM32F103 die oberflächlich vielleicht funktionieren, aber wenn es ans eingemachte geht aufgeben. https://dse-faq.elektronik-kompendium.de/dse-faq.htm#F.7.3.1 Keiner tut sich das noch an, da nach der Ursache der Fehler zu suchen.
Christian J. schrieb: > Wie sind da eure Erfahrungen? z.Zt. sind auf ca 99% aller ausgelieferten BluePillBoards gar keine STM Chips mehr drauf.
MaWin schrieb: > Keiner tut sich das noch an, da nach der Ursache der Fehler zu suchen. Sehr schade, das war vor 5 Jahren ein klasse Maschinchen für den schnellen Aufbau aber das was ich hier jetzt noch liegen habe ist einfach nur Schrott :-( 25 Euro für 5 Stück kamen gestern. Und die schwarzen F103 Platinen haben andere Pins und sind zudem nur 36 Pinner. 5V fehlt da und einige GNDs. Black Pills habe ich 3 Stück, die spielen sind aber nicht mal eben austauschbar, weil die eine andere API haben und die I2C ist sehr anders.
Dann wohl doch noch paar Boards mehr mit den 64pinnern bauen?
Jörg W. schrieb: > Dann wohl doch noch paar Boards mehr mit den 64pinnern bauen? :-)) Ja, ich denke das wäre eine Marktlücke! Wobei... dieses Blinky läuft auf einigen, blockiert dir bloss den swd komplett aber es blinkt. Wobei ich defintiv sagen kann, das das Brett trotzdem defekt ist, weil der I2C Bus sich direkt aufhängt im Master Mode und der ist bei mir 100% abgesichert per Timeouts. Bei 2 lässt sich LSE nicht aktivieren, da hängt er schon in der Routine, die den Einschwingvorgang überwacht. Das Theater mit I2C war hier ja schon oft Thema die letzte Zeit. Das Teil ist ja auch sehr "unübersichtlich" beim M3.
Christian J. schrieb: > Grosser Mist: Die Hälfte der Boards sind defekt! Glaub ich nicht. Ich hab dich hier ja schon öfters erlebt und du gehörst auch zu der Sorte von Leuten die von ihrer Hardware alles fordern ohne auf deren Befindlichkeit(en) einzugehen. Null (!!) Kondensatoren zum Puffern zu sehen. Braucht's keine, gell? Geht ja auch ohne. Also wozu den kostspieligen Überfluss an Hardware dazufrickeln, oh weh, oh weh. Sparen, sparen .... sonst muss man ja soviel löten. Und Kondensatoren kosten ja soviel .... Ein Akku bzw eine Batterie ist übrigens besonders ungünstig wenn seine Spannung nicht gepuffert und stabilisiert ist da er/sie sehr "weich" ist. Also optimal für Fehlfunktionen. Und nein, die Kondensatoren auf den einzelnen Modulen reichen nicht aus! Aber das alles an Problemen machst du ja mit deiner fehlertoleranten Programmierung mehr als wett. Es gibt also keinen Grund für weiteres Handeln. OMG
hard werker schrieb: > Null (!!) Kondensatoren zum Puffern zu sehen. Die sind doch alle nur für Warmduscher. MaWin schrieb: > Keiner tut sich das noch an, da nach der Ursache der Fehler zu suchen. Dazu braucht man nur die DBs der eingesetzten Chips zu lesen, die sich von den STMs in einigen Punkten unterscheiden.
Andreas B. schrieb: > Dazu braucht man nur die DBs der eingesetzten Chips zu lesen, die sich > von den STMs in einigen Punkten unterscheiden. Bloss woher weiss man, welche chinesischen Ausschusschips die in vielleicht in 5 Maskenrevisionen ihr Datenblatt erreichen werden, in dem schwarzen Epoxygehäuse stecken, das natürlich mit STM32F103C8T6 bestempelt ist ?
hard werker schrieb: > Ein Akku bzw eine Batterie ist übrigens besonders ungünstig > wenn seine Spannung nicht gepuffert und stabilisiert ist da > er/sie sehr "weich" ist. Also optimal für Fehlfunktionen. Selten so einen Quatsch gelesen bei einem Board, was maximal 60mA zieht und im Normalbetrieb auf 28 mA kommt, weil die CPU extrem tief taktet. Du weisst, dass diese Akkus locker 5A liefern? Die explodieren förmlich wenn man sie kurz schliesst. Den Kondensatorquatsch braucht wirklich niemand, völlig überbewertet. Relikt aus den Röhren-Ära. Das Oszillogramm von VCC an allen Baugruppen ist ein gerader Strich... der nicht mal zuckt, wenn das GPS zuschaltet! Gehe ich auch nicht weiter drauf ein..... Troll Geschwätz eben.
Christian J. schrieb: > Den Kondensatorquatsch braucht wirklich niemand, völlig überbewertet. Drum schreibt das auch extra keiner in irgendein Datenblatt...
Lothar M. schrieb: >> Den Kondensatorquatsch braucht wirklich niemand, völlig überbewertet. > Drum schreibt das auch extra keiner in irgendein Datenblatt... Das war überspitzt ironisch gemeint :-) Aber Bauteile die sich im mA Bereich bewegen an einer Quelle mit wenigen MilliOhm Ri brauchen wirklich keine Blocker oder Elkos, wenn man sternförmig verlegt. Das einzige was HF erzeugt ist die SPI. Die geht bis max 6-8Mhz, dann werden die Flanken unscharf und es enstehen Fehler. betrieben wird sie mit 3.5Mhz SCLK. Der Rest schweigt die meiste Zeit einfach. DC/DC Wandler 3.3V ist heikel aber noch im Rahmen, ca 0,05V schwankt der um die 3.3V mit 100khz. Die BP's sind kaputt bzw Teile davon. Die Core ID's sind ja schon unterschiedlich wenn ich die auslese.
Christian J. schrieb: > Aber Bauteile die sich im mA Bereich bewegen Im Mittel? Der Witz ist der, dass immer genau an der Taktflanke der Strombedarf eben deutlich höher ist als der Mittelwert. Und wenn dann mal zufällig etwas mehr zusammenkommt, dann spinnt der uC halt. Oder andersrum: wenn ein uC spinnt und keine Blockkondensatoren hat, dann würde ich erst mal eine Handvoll 0402 oder 0201 mit 10nF zwischen die Versorgungspins löten.
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Der Witz ist der, dass immer genau an der Taktflanke der Strombedarf > eben deutlich höher ist als der Mittelwert. Dieser Christian J. ist leider voll beratungsreistent was man an seiner Ausdrucksweise immer wieder live erleben kann. Er hat die Prinzipien von Abblock-Kondensatoren nicht verstanden und wird es auch in Zukunft nicht verstehen. Reisende soll man nicht aufhalten.
Angehängte Dateien:
-
STM32-Blue-Pill-Board.jpg
120 KB
Lothar M. schrieb: > Oder andersrum: wenn ein uC spinnt und keine Blockkondensatoren hat, > dann würde ich erst mal eine Handvoll 0402 oder 0201 mit 10nF zwischen > die Versorgungspins löten. Lothar... diese Board funktionieren so wie man sie kauft. Ein Blick drunter zeigt auch, dass da einiges dran ist, jeder GND ist gegen Vcc geblockt. Zudem sind noch 3 x GND herausgeführt, die alle mit GND verbunden werden, jeder Pin an seinem eigenen Draht. Und bitte traue mir zu einen Oszi richtig zu bedienen, der eindeutig zeigt, dass die Baugruppen das bekommen was sie brauchen :-) Keine Baugruppe taktet irgendwo herum, nur auf ihrem Brettchen. Und ja, die I2C Flanken habe ich mir auch angeschaut, die sind wie aus dem Lehrbuch mit 4k7 gegen Vcc. edit: 5 x 100nF an allen Modulen, direkt auf Vcc-GND änderten nichts. Schaden tun sie nicht, bewirken aber auch nichts. Denke das Thema ist durch, die Rot-Punkte sind auch jetzt im Müll.
MaWin schrieb: > Bloss woher weiss man, welche chinesischen Ausschusschips die in > vielleicht in 5 Maskenrevisionen ihr Datenblatt erreichen werden, in dem > schwarzen Epoxygehäuse stecken, das natürlich mit STM32F103C8T6 > bestempelt ist ? Bis jetzt habe ich immer das bekommen was auf den Chips drauf stand. Das stimmt zwar nicht immer mit der Händlerbeschreibung überein, aber das ist ein anderes Thema.
Christian J. schrieb: > 25 Euro für 5 Stück kamen gestern. Christian, es hat sich doch schon bis in die letzten Ecken dieses Forums herumgesprochen, dass die Chinesen auf die BluePills nur noch Fakes oder Clones draufkleben. Du hast Dich sogar teilweise an diesen Diskussionen beteiligt! Und jetzt kaufst Du 5 Stück und lamentierst, dass sie nicht funktionieren!? Ich verstehe Dich wirklich nicht. Nimm es hin: BluePills sind tot. Die STM32F4x1-BlackPills funktionieren aber ebensogut, wenn man kein CAN braucht. Und die kosten auch nur 2 bis 3 EUR. Christian J. schrieb: > Black Pills habe ich 3 Stück, die spielen sind aber nicht mal eben > austauschbar, weil die eine andere API haben und die I2C ist sehr > anders. Komisch, meine I2C-Routinen laufen sowohl auf STM32F103 als auch auf STM32F4xx einwandfrei - lediglich eine Handvoll von Code-Zeilen sind verschieden. Das erledigt dann der Preprocessor. Wenn Du Problem mit I2C auf STM32F4xx Probleme hast, sind Deine I2C-Routinen einfach Murks. Meine findest Du (in abgewandelten Varianten) zum Beispiel in MINOS, STECCY und WordClock mit WS2812 - einfach mal anschauen. Ich kann sie Dir auch zuschicken, wenn Du möchtest.
Christian J. schrieb: > Den Kondensatorquatsch braucht wirklich niemand, völlig überbewertet. > Relikt aus den Röhren-Ära. Jetzt wissen wir wo das Problem mit 100% Sicherheit verortet ist: Vor der Tastatur. Arroganz und Dummheit sind schon eine fiese Kombination.
Frank M. schrieb: > Komisch, meine I2C-Routinen laufen sowohl auf STM32F103 als auch auf > STM32F4xx einwandfrei - lediglich eine Handvoll von Code-Zeilen sind > verschieden Besser hätte man nicht belegen können, dass die I2C Routinen eines 103 auf dem 4xx nicht funktionieren.
Christian J. schrieb: > Das Oszillogramm von VCC an allen Baugruppen ist ein gerader Strich... > der nicht mal zuckt, wenn das GPS zuschaltet! Ja ne ist klar. Vergesst den BluePill Mist, selber ein kleines Board designen, Platinen bestellen und die Bauteile original von Mouser oÄ. dann hat man keine Probleme. Kostet dann pro Stück halt 4 Euro statt 2, KOLOSSAL! So mache ich das und hatte noch nie ein Problem, aber Hauptsache Geiz ist geil. Dein "Oszillogram" Welches Oszi, welcher Tastkopf, welcher Aufbau? Wahrscheinlich schön am 50Mhz Oszi mit Tastkopf und 10cm Massekabel.... Ein paar Kondensatoren und ein Ferrit kosten fast nix also warum nicht einbauen? Für jedes IC einen 1u Tantal und 100nF Kerko über einen Ferrit hat sich bewährt. Übrigens, man sieht es auch beim EMV Test (machst du klarerweise fürs Hobby nicht) also der Effekt IST da. Zum Spaß steht es nicht in den Datenblättern.
Sollte die Behauptung "BluePills sind tot." stimmen, sollte das sich in den Bewertungen bei Ebay widerspiegeln. Zumindest bei den Verkäufern (4) aus dem Reich der Mitte bei denen ich nachgeschaut habe war das nicht der Fall.
MaWin schrieb: > Besser hätte man nicht belegen können, dass die I2C Routinen eines 103 > auf dem 4xx nicht funktionieren. Ich bezog mich hier auf Christians Aussage - und die hatte ich auch zitiert: > die I2C ist sehr anders. Das stimmt einfach nicht, die Ansteuerung ist nur minimal verschieden.
Moin, zunächst einmal muss ich mich für etwas entschuldigen. Wobei... einfach zu finden war das nicht, vor allem, wenn man bis 4 Uhr morgens das Problem sucht warum die Chips nach dem Flashen von Blinky keinen Reset mehr ausführen. Kein WDT, kein NVIC. Und zwar alle. Unerklärlich. Option Bytes sind richtig gesetzt, alle kontrolliert. Die BP's sind nicht "kaputt", ok, 2 sind es, da sind Pins tot. Vermutlich durch ESD und da ewige Anfassen. Ich flashe 82kb Code, weil ich mich dran gewöhnt und darauf vertraut habe, dass Eblink das schon richtig macht. Sieht ja auch so aus. Ich habe den Code grad mal um 30kb gekürzt, so dass nur noch Blinkies und Display laufen. (Es sind übrigens nicht fehlende C's, waren es auch nie) Mit ca 40kb laufen die roten Boards. Nehme ich die Defines wieder rein, die Segmente freischalten bzw Funktionen die keinerlei Hardware benötigen (Berechnungen,sin, cos usw) geht es nicht mehr. Der Debugger bleibt einfach stehen. Abgeschmiert. Kommt öfter vor, also nicht auffällig. st-link Utility meldet die roten Boards mit 64kb, die anderen mit 128kb. Wer hat recht? Das ST Tool was der Hersteller heraus gibt? Oder eine Open Source Software? Vermutung: Eblink Verify merkt es nicht, dass da über 64kb gar nichts geflasht wurde. Warum auch immer. Nochmal: Der flasht 80kb rein, obwohl die Chips nur 64kb haben. Erkennt sie aber als 128kb. Vermutung: Und natürlich schmieren die ab, wenn der Code irgendwann dahin kommt wo keiner ist oder kaputter Code etc. Vor 3 Jahren habe ich 2 Boards mit echten 128kb Chips von ST bestückt, bestellt bei Mouser. Die habe ich grad mal rausgerissen aus der Wetterstation. Schluss mit den Fakes. --------------------------------------------------------- Und die mit 80kb bespielt.... es läuft alles! Problemlos! --------------------------------------------------------- Tiefer werde ich da nicht einsteigen, werde das Board verwenden mit dem echten ST, den ich damals habe drauflöten lassen und gut. Rest dürfte vergeudetet Zeit sein. Nochmals Entschuldigung, ich habe da wohl Fehlschlüsse gezogen :-(
F. M. schrieb: > Ein paar Kondensatoren und ein Ferrit kosten fast nix also warum nicht > einbauen? Tut mir leid, aber diese Problem tauchten noch bei niemand auf, der Arduino Baugruppen verwendet. Und die sind alle aus diesem Baukasten. Nirgendwo ist im Netz die Rede davon die noch extra zu blocken. Und ich habe hunderte Seiten besucht bei meinen Recherchen. Die Baugruppen sind (meist) so, dass sie AsIs verwendet werden können.Zudem nirgendwo echte Taktraten spielen, das ganze System ist Low Power und maximal 100khz auf 3-4cm Kabel. Darüber kannste Dir Gedanken machen bei einem Komplettdesign, wo alles auf eine Platine kommt. Thema möchte ich auch nicht diskutieren, da bin ich anderer Meinung und somit "unbelehrbar".
> Die BP's sind nicht "kaputt", ...
Danke für die Rückmeldung und die Bestätigung meines Einwandes.
PS: Riskant ist mein Einsatz von Step/Up/Down 3.3V Wandlern mit Enable. Die haben 2 Stufen drauf. 18650 sind nutzbar von 3-4.2V. 200uA Leckstrom. Jeder AMS1117 hat deutlich mehr. Für mich zuviel.18650 sind nicht ideal für 3.3V Anwendungen aber haben genug Power das Ding 2 Wochen zu betreiben. Alles ist 3.3V, auch das EEPROM ein LC type, der Rest sowieso. 5V Regler sind überall abgelötet, die ziehen Strom wenn ihre Ausgänge mit 3.V bespielt werden. Auch die BP's habe alle keine 5V Regler mehr drauf. Die erzeugen aus 2.5V 3.3 aber auch aus 5V und mehr. Die habe ich mir angeschaut, auch deren Startverhalten, Klebt man denen 100uF hinter starten sie teilweise gar nicht mehr. 100nf haben sie. f ist 100khz, erzeugt natürlich einen Ripple, der ca 0.05V gross ist. Damit kommt das BP aber klar, der PVD aktiviert (Spgüberwachung per Interrupt, auf 2.9V eingestellt). Nen Ferrit, ggf ein LC Filter wäre nicht verkehrt, müsste ich mal testen auf einem Breadboard. Habe noch genug 50uF und 100uH Ferrite mit kleinem R.
Christian J. schrieb: > Der flasht 80kb rein, obwohl > die Chips nur 64kb haben. Dann sollten aber die letzten 16kB wieder an den Anfang geschrieben werden. Vielleicht ist das Verify fehlerhaft, daß es nicht merkt, daß der Startupcode zerschossen wurde.
Peter D. schrieb: > Dann sollten aber die letzten 16kB wieder an den Anfang geschrieben > werden. > Vielleicht ist das Verify fehlerhaft, daß es nicht merkt, daß der > Startupcode zerschossen wurde. Das vermute ich mal ganz stark, dass der Zähler da zurück setzt. Der Verify würde nichts merken. Andererseits suche ich in "Fake-Chips" nach Problemen mit einem 5 Euro Fake-Flash Tool mit Open Source Software ... schlimmer geht es eigentlich nicht mehr. Zudem sich die sog. Core Ids ziemlich unterscheiden. Der EBlink ignoriert die einfach, das ST Tool meckert sofort "Core ID not matching!"
Andreas B. schrieb: > Bis jetzt habe ich immer... Und welchen Bezug hat das zum Thema? Gar keinen. Ich selber hab vor einiger Zeit bei LCSC einige GD32F303RCT6 bestellt und gekommen sind STM32F303RCT6 gemäß aufgelaserter Bezeichnung. Und neulich kam eine Sendung von AD820 an, die jedoch in ihrem elektrischen Verhalten keinerlei Ähnlichkeiten mit OpV's haben. Was lernen wir daraus: derzeit ist die gesamte Chipbranche in Chinas Handel versaut, draufgelasert wird, was der Kunde grad bestellt hat - unabhängig vom drinsteckenden Silizium. Das Problem ist weitaus größer als nur bei den Blue-Pill-Boards. W.S.
W.S. schrieb: > Das Problem ist weitaus größer als nur bei den Blue-Pill-Boards. Ohne in Details zu gehen, das Problem hat auch die Industrie erreicht. Dass nicht mehr das drin ist was drauf steht. Zumindest wenn man Second Sources bedient, weil der OEM oder First Tear Supplier nicht liefern kann.
Baldmann schrieb: > sollte das sich in den Bewertungen bei Ebay widerspiegeln... Man sollte sich von dem Glauben verabschieden, daß Bewertungen bei Ebay, Ali oder Amazon von irgend einer Relevanz sind. Claqueure hatte man früher dazu gesagt. W.S.
W.S. schrieb: > Man sollte sich von dem Glauben verabschieden, daß Bewertungen bei Ebay, > Ali oder Amazon von irgend einer Relevanz sind. Claqueure hatte man > früher dazu gesagt. Na und. Selbst gekaufte positive Bewertungen können die vielen negativen wegen nicht funktionierenden Boards nicht verschwinden lassen.
Cyblord -. schrieb: > Na und. Selbst gekaufte positive Bewertungen können die vielen negativen > wegen nicht funktionierenden Boards nicht verschwinden lassen. Wozu auch, wenn nach 1000 gekauften super Bewertungen die ersten negativen auftauchen, wird der Shop geschlossen, ein neuer aufgemacht und das Spiel beginnt von vorn.
Christian J. schrieb: > st-link Utility meldet die roten Boards mit 64kb, > die anderen mit 128kb Der STM32F103C8T6 meldet sich immer mit 64K Flash. Er kann mehr Flash haben, aber meldet immer nur 64K zurück. Die Boards mit 128K sind offensichtlich nicht mit einem STM32F103C8T6 bestückt. Falls "STM32F103C8T6" auf dem Chip drauf steht, dann ist er eine Fälschung. Wie bereits festgestellt wurde: das Problem befindet sich vor der Tastatur. Du flashst mit einem dubiosen Tool mehr auf den µC als offiziell drauf paßt und wunderst dich dann, daß nichts funktioniert. <kopfschüttelnd>
Axel S. schrieb: > Die Boards mit 128K sind offensichtlich nicht mit einem STM32F103C8T6 > bestückt. Falls "STM32F103C8T6" auf dem Chip drauf steht, dann ist er > eine Fälschung. Nein, genau das ist ein Indiz für einen Original Chip. Und das ist auch seit Jahren bekannt. Nur einige ‚kompatible‘ haben tatsächlich nur 64 kB. Und dubiose Tools wie OpenOCD konnten das schon lange nutzen.
Axel S. schrieb: > Der STM32F103C8T6 meldet sich immer mit 64K Flash. Er kann mehr Flash > haben, aber meldet immer nur 64K zurück. richtig weshalb man auch nur diese 64k verwenden sollte. Viele der Clone haben tatsächlich nur diese 64k. Ein Baustein der 128k meldet muss also zwangsläufig ein Klone sein (GIGA Device). Wenn der dann noch mit STM beschriftet ist ist's kein Klon sondern eine Fälschung. Das Tool wird einfach nur Buggy sein, so dass die Annahmen halt nicht stimmen. Etwas OT: Ich suche immer noch ein BluePillBoard was mit einem CH32F106 bestückt ist. Wer eines übrig hat soll sich bei mir melden.
Axel S. schrieb: > Wie bereits festgestellt wurde: das Problem befindet sich vor der > Tastatur. Du flashst mit einem dubiosen Tool mehr auf den µC als > offiziell drauf paßt und wunderst dich dann, daß nichts funktioniert Axel, irgendwo ist doch alles womit gebastelt wird "dubios". Es sei denn Du kaufst dir eine Toolchain bei IAR oder Keil und weisst, dass alles qualifiziert ist. EmBitz 1.1 China Debug Tool Fake Chips EBlink Debug Server (komplexes Tool, Riesenprojekt im Netz und der, der es betreut hat echt Ahnung) https://github.com/EmBitz/EBlink schlimmer geht es nimmer. Und trotzdem wird es verwendet. Genauso wie unzählige Arduino Libs, die weder geprüft sind noch dokumentiert.... und zigtausende basteln damit. Der Baustein mit 128 ist ein anderer F103??, der hat wirklich 128kb. Hatte ich mir extra gekauft damals 2017 und die auflöten lassen. Und es sind alle mit STM beschriftet, also alles Fälschungen, Klone usw. Es gibt eben nichts anderes mehr.
Johannes S. schrieb: > Und dubiose Tools wie OpenOCD konnten das schon lange nutzen. Was ist an OpenOCD dubios. Man konfiguriert das Ziel. Und ich finde diese Flexibilität gut.
Johannes S. schrieb: > Nein, genau das ist ein Indiz für einen Original Chip. Und das ist auch > seit Jahren bekannt. Nein, ist es nicht. Alle werden mit 64kb gemeldet und davon ist ganz sicher kein einziger echt. Aber fast alle sind mit 128kb bespielbar (ohne Gewähr!), ich habe schon 121kb gedebugged und das lief auch. Nur eben nicht mit ST Software, die verweigert das komplett. OpenOCD und EBlink aber nicht.
noreply@noreply.com schrieb: > Was ist an OpenOCD dubios. Man konfiguriert das Ziel. Und ich finde > diese Flexibilität gut. Kanste mit EBlink auch, einfach ein Script anlegen, das den Chip typisiert und schon frisst das Ding alles. Kinderleichte Bedienung über cmd Shell.
Johannes S. schrieb: > Axel S. schrieb: >> Die Boards mit 128K sind offensichtlich nicht mit einem STM32F103C8T6 >> bestückt. Falls "STM32F103C8T6" auf dem Chip drauf steht, dann ist er >> eine Fälschung. > > Nein, genau das ist ein Indiz für einen Original Chip. Und das ist auch > seit Jahren bekannt. Nur einige ‚kompatible‘ haben tatsächlich nur 64 > kB. Lies es nochmal. Ein STM32F103C8T6 kann mehr Flash haben, er meldet aber immer nur 64K. Wenn er angibt 128K Flash zu haben, ist es entweder ein STM32F103CBT6 (man beachte das B statt der 8). Oder eben ein Klon. Und wenn dann STM drauf steht, eine Fälschung. Um einen STM32F103C8T6 mit mehr als 64K Flash zu beschreiben, kann man openOCD verwenden. Nur sollte man vorher testen, ob man eine Charge erwischt hat, die auch wirklich 128K hat. Die "dubiose Software" ist Eblink. Was immer das ist.
Axel S. schrieb: > Lies es nochmal. Ein STM32F103C8T6 kann mehr Flash haben, er meldet aber > immer nur 64K. Korrekt, das Original meldet immer 64KB. Man vermutet hier, dass ST den gleichen Wafer für STM32F103C8T6 und STM32F103CBT6 verwendet und lediglich eine Fuse wegschießt, um daraus einen STM32F103C8T6 zu machen - aus welchen Gründen auch immer. Es kann sein, dass bei bestimmten Margen eine Hälfte des 128K Flashs nicht den Qualitätsansprüchen von ST genügt. Dann wird da halt der kleine Bruder des STM32F103CBT6 daraus. Trotzdem kann man - zum Beispiel über einen Bootloader - durchaus 128K flashen, dann halt ohne Garantie. Die Original-STLinks verweigern das aber. > Wenn er angibt 128K Flash zu haben, ist es entweder ein > STM32F103CBT6 (man beachte das B statt der 8). Oder eben ein Klon. Und > wenn dann STM drauf steht, eine Fälschung. Genau so ist es. Das wurde hier schon in unzähligen Threads so bestätigt und komplett durchdiskutiert.
:
Bearbeitet durch Moderator
Cyblord -. schrieb: > Selbst gekaufte positive Bewertungen können die vielen negativen > wegen nicht funktionierenden Boards nicht verschwinden lassen. Der Verkäufer lässt die negativen verschwinden. Bzw. Ebay natürlich. Ich finde jedenfalls nicht alle meiner - ohnehin sehr wenigen - negativen Bewertungen von chinesischen Schrott wieder. Das Bewertungssystem ist so oder so (egal ob Amazon oder Ebay) mit Vorsicht zu geniessen - auf Ebay gibts eh nur Kurztexte, die eher den Ablauf schildern sollen und daneben irgendwelche separate Produktbewertungen - und Amazon ist das Reich der gekauften Fake-Bewertungen.
MeierKurt schrieb: > Der Verkäufer lässt die negativen verschwinden. Bzw. Ebay natürlich. > Ich finde jedenfalls nicht alle meiner - ohnehin sehr wenigen - > negativen Bewertungen von chinesischen Schrott wieder. Unsinn. Kommt hier die nächste Schauergeschichte? Der böse Chinese lässt zusammen mit Evil Ebay Bewertungen verschwinden? Also bitte mal auf dem Teppich bleiben.
Moin, ich versuche es hier nochmal: Seit dem Testen der 10 Boards mit diesem Blinky von Greasle (diverse Testroutinen für I2C etc) erlaubt kein einziges meiner Pillen mehr einen Reset! Nochmal: Ein Softreset NVIC_SystemReset() oder selbst durch den WDT endet in einem Stillstand. Wie das??? 7 Stunden habe ich gesucht, nichts gefunden, alles nur denkbare durch probiert. Option Bytes geprüft, mit und ohne Boot0 Jumper gelöscht, alles. Ich drehe noch ab, da ich zwingend auf den Reset angewiesen bin, wie ist egal. Ich frage mich ernstnhaft was dieses Testprogramm damit gemacht hat, denn selbst eine 4 Wochen alte Sicherheitskopie meiner Anwendung läuft jetzt nicht mehr. Abeeeer: Das Flasher Tool Eblink kann das auch! Flasht man einen Stein aus der IDE heraus, wird das Prog durch eblink .... -flash -verify run Parameter sofort gestartet über die swd. Aber.... der Reset Knopf ist blockiert. Keine Wirkung! Erst nach ein/aus ist er wieder da. Dass man den NRST / Reset abschalten kann war mir absolut neu. Der liegt über einen PU an Vcc mit Taster. Info: EBlink wurde durch Gerard Zegema geschrieben, ein holl. Software Guru, der auch Embitz geschrieben hat und laut LinkedIn bei NXP Semiconductor arbeitet. Also Ahnung zu haben scheint.
Beitrag #6721285 wurde von einem Moderator gelöscht.
Hallo Christian,
>>Nochmal:
Als Privater hat dir ein Strandhändler seine Kloschüssel
hingehalten..und du hast zugegriffen.
Nun verstanden?
Was du da bekommen hast, es kann keiner sagen was es ist. Unbekannter
Zustand und Qualität( kann man das noch so sagen?).
Als Firma: Habe die Tage 32x STM32F412 von ST als MUSTER kostenlos
bekommen. Wir brauchen die nächsten 5 Jahre insgesamt so 11.000 Stück.
Da werde ich einige BluePills mit den STM32F401 holen und die gegen die
412 beim Bestücker tauschen lassen.
VG
Peter
Angehängte Dateien:
-
p1.JPG
42 KB
Pieter schrieb: > Als Privater hat dir ein Strandhändler seine Kloschüssel > hingehalten..und du hast zugegriffen. Hat damit nichts zu tun, überhaupt nichts. An meiner Embitz IDE ist was verkonfiguriert, die neuen Boards die heute kamen (2 Pillen für 18 Euro... wie an der Börse :-) haben das gleiche Problem: Die Reset Logik lässt sich nicht mehr ansteuern. Da das normalerweise unmöglich ist glaube ich auch bald an UFOs. Und nach 2 Tagen sinnlosem Suchen fehlt mir bald echt die Lust....
Hast du dir was in deinen SPL etwas falsch zusammengemixt? Benutzt du wenigstens git um das Chaos zu kontrollieren?
Johannes S. schrieb: > Benutzt du wenigstens git um das Chaos zu kontrollieren? Was bitte? Ich habe eine Festplatte und einen Backup Server der jede Stunde ein Backup macht. GIT kenne ich mich nicht mit aus, weiss nur dass es das gibt. Naja, viel kann man ja nicht vermurksen. Aber das "Phänomen" ist mir neu. Ja, sogar den Reset Knopf kann man außer Betrieb nehmen. Dazu muss man nur die Vector Table vermodeln. Dann geht der auch nicht mehr. Aber die SPL und CMSIS mal überbügeln... die Idee ist nicht verkehrt.
Dann hast du im Backup immer schön den gleichen Stand, bzw. max den von vor einer Stunde. Mit git kann man die Experimente wesentlich kontrollierter machen und eine gute GUI / IDE zeigt dir Änderungen mit einem Klick an. Es lohnt sich dafür Zeit zu investieren, die holt man vielfach wieder raus.
Christian J. schrieb: > Ich habe eine Festplatte und einen Backup Server der jede Stunde ein > Backup macht. Kann man machen, aber eine Versionsverwaltung hat den Vorteil, dass du außer dem stupiden Zurückdrehen auch noch Metadaten dazu notieren kannst (Begründung deiner Änderungen).
Johannes S. schrieb: > Dann hast du im Backup immer schön den gleichen Stand, bzw. max den von > vor einer Stunde. ja, leider.. aber besser als nix. Vor großen Modeleien mache ich ein Backup so direkt, damit ich es nachher zurückspielen kann. Hast Du Embitz? Dann könntest du das hier direkt anklicken und mit der ebp Daztei startet alles: https://drive.google.com/file/d/1tFv6oDnVCbt30n1J1I3uKoSr1gJnWPVr/view?usp=sharing
Christian J. schrieb: > Vor großen Modeleien mache ich ein Backup so direkt, damit ich es > nachher zurückspielen kann. Und mit git würdest du sofort sehen welche Dateien du geändert hast und auch was du geändert hast. Embitz habe ich auf dem aktuellen Rechner nicht mehr drauf. Wenn ich am WE Langeweile haben sollte…
Johannes S. schrieb: > Embitz habe ich auf dem aktuellen Rechner nicht mehr drauf. Wenn ich am > WE Langeweile haben sollte… Da werde ich endlich wieder in meinem geliebten Sachsen sein, in den Armen meiner Liebsten, im Garten der lauen Sommerluft, Grillen.... Wein trinken.... und so gar nichts über Technik reden, weil das Frauen sowas von abtörnt :-) Ich darf nicht mal das Netbook mitnehmen, da ich mich damit ja zu Hause per vpn anbinden könnte...
Christian J. schrieb: > Vector Table vermodeln An die Vector Tabelle habe ich heute Nachmittag auch schon gedacht. Aber das sollte man im Binary bzw. Flash prüfen. Aber da würde dann das Programm in der Blue Pill nicht mehr hochfahren. Btw. Für 9 Euro das Stück kann ich auch in meinen Zentrallager nachschauen und liefern. ;-) NOS, orginalverpackt.
Angehängte Dateien:
-
photo_2021-06-09_22-54-20.jpg
110 KB -
p2.JPG
35 KB
noreply@noreply.com schrieb: > An die Vector Tabelle habe ich heute Nachmittag auch schon gedacht. Aber > das sollte man im Binary bzw. Flash prüfen. Aber da würde dann das > Programm in der Blue Pill nicht mehr hochfahren. Tja, mit meinem Infrarot Debugger mangels freier UART ist das mühselig, da normaler Debug mit Stop und Sleep nicht mehr funktioniert. Aber nach dem Stop was er gesendet hat wurde es dunkel um ihn. Kein Reset. Auch nicht mit den gerade eben geplätteten CMSIS und SPL. Ich überlege schon eine Belohnung aus zu schreiben, um dieses Problem zu lösen. Beim dsb ist Schluss, da endet der Debugger beim NVIC_SystemReset.
Beitrag #6721735 wurde von einem Moderator gelöscht.
Beitrag #6721738 wurde von einem Moderator gelöscht.
Beitrag #6721754 wurde von einem Moderator gelöscht.
Beitrag #6721760 wurde von einem Moderator gelöscht.
Ok, da kein Mod diesen AntiFa-Kaspar hier raus wirft.... hat sich alles in Luft aufgelöst. Eine winzige Brücke hatte sich gebildet zum R Pin der Boards von einem CUL Kabel was + führte. Zu sehen war sie nicht, nur zu erpiepsen. Und darum war der Reset blockiert und zwar alle Resets klappen dann nicht mehr. Dass sowas geht dachte ich nicht aber nachher ist man ja immer schlauer. Thema durch.... auch wenn die Lösung keine blauen Männchen oder dreiste Fälscher waren.
Christian J. schrieb: > Thema durch.... auch wenn die Lösung keine blauen Männchen oder dreiste > Fälscher waren. du kannst doch nicht einfach so die Weltbilder hier zerstören...
Frank M. schrieb: > Es kann sein, dass bei bestimmten > Margen eine Hälfte des 128K Flashs nicht den Qualitätsansprüchen von ST > genügt. Der Test verursacht einen Teil der Produktionskosten und halb so viel testen kostet halb so viel Zeit. Also wird das getestet, was man gerade benötigt, und wenns nicht passt, weggeworfen. Binning lohnt bei dem Kleinkram nicht. Werden die aussortierten Teile in voller Kapazität verwendet, sind sie dann eben zur Hälfte ungetestet.
:
Bearbeitet durch User
Moin. Thema ist zwar durch, aber so als Nachtrag: Ich bin zwar nicht so der Elektronikfreak wie ich es gerne hätte, aber mit STM32 kenne ich mich ein wenig aus. Selbst die China-Klone und Fälschungen(*) (also die Chips) funktionieren in 99,99% der Fälle. Ich will nicht sagen "einwandfrei" - Einwände gibt es immer - aber meistens sind es nicht die Chips, die den Schwachpunkt auf den White/Black/BluePills darstellen. Und auch auf die Gefahr hin hier auch gleich als "AntiFa-Kasper" bezeichnet zu werden: Wenn ich mir das ursprüngliche Originalbild in diesem Thread anschaue, dann sind nicht die Blauen Pillen der Schwachpunkt... Vielleicht geschehen ja noch magische Dinge auf der Rückseite des Boards aber ich sehe keine SCL/SDA Pullups (I2C hängt sich auf) - ich sehe auch nicht den I2C code (I2C hängt sich auf). Da fange ich nicht als erstes an die 18650 ode fehlende Kondis zu verdächtigen. Mueh (*) Unterschied zwischen Klon und Fälschung bekannt - ja?
Alfons K. schrieb: > Unterschied zwischen Klon und Fälschung bekannt Eine Fälschung isses, wenn sie auf den Klon "ST" drauf stempeln.
(prx) A. K. schrieb: > Werden die aussortierten Teile in voller Kapazität verwendet, sind sie > dann eben zur Hälfte ungetestet. Man streiche "aussortierten". Es sind natürlich die nicht aussortieren, die nur halb getestet sind. Die aussortierten Teile sind ja als defekt rausgefallen. Sie können aber je nach Art des Fehlers dennoch unter eingeschränkten Bedingungen verwendbar sein. Ist halt Glücksache.
Jörg W. schrieb: > Alfons K. schrieb: >> Unterschied zwischen Klon und Fälschung bekannt > > Eine Fälschung isses, wenn sie auf den Klon "ST" drauf stempeln. Exakt. Was auf die Funktionalität bekanntlich keinen Einfluss hat. Ergo verhält sich eine Fälschung wie ein Klon. Nur halt für jemanden unerwartet. Wie dem auch sei: die Klone funktionieren, die Original ST-Link Firmware mag die nicht (kann ich aber verstehen). Manche "Blue Pill" Boards sind leider sehr nachlässig zusammengeschustert. Mein Hoflieferant - ich glaube ja nicht, dass er so doof ist wie er tut - spricht im übrigen beharrlich (trotz ausführlicher Korrespondenz hierzu) von "Klon" auch wenn da ST drauf gestempelt ist. Vermutlich wäre Gegenteiliges schlecht fürs Geschäft.
Alfons K. schrieb: > Selbst die China-Klone und > Fälschungen(*) (also die Chips) funktionieren in 99,99% der Fälle. Nein, tun sie nicht! Die mit den roten Punkten sind alle defekt gewesen! Überall funktionierte I2C nicht! Was genau habe ich mir nicht die Mühe gemacht, da meine Software da fehlerfrei ist. Und komischerweise bei den anderen lief es. Und das ist für Software nunmal seeeehr ungewöhnlich. Bei zweien lief auch das sog. Blinky Test nicht, was alle Teile des Bausteins durchtestet auf bekannte Ursachen.
Christian J. schrieb: > Überall funktionierte I2C nicht! Dass paar Beiträge weiter oben fehlende Pullups am I²C moniert worden sind, hast du aber mitbekommen, oder? Nur mit eingebauten Pullups mutiert I²C auch nach meiner Erfahrung schnell zum Glücksspiel.
Angehängte Dateien:
-
p1.JPG
21 KB
Jörg W. schrieb: > Dass paar Beiträge weiter oben fehlende Pullups am I²C moniert worden > sind, hast du aber mitbekommen, oder? Ich habe 3 Bausteine und bei Widerständen löte ich auch gerne mal unter der Platine, denn da ist auch einiges.(zb. die Vorwiderstände der LEDs) Der Bus ist in Summe mit 2.2k aufgehängt an den Open Collector Pins. Und auf dem Oszi sieht das alles gut aus. 4.7k sind bisher gut gewesen, 10k sind zu wenig.Auf Masse ist die Leitungskapazität ja sofort gelegt, bis die Leitungkapazität aber wieder auf 3.3V Volt ist, ist abhängig vom Ladewiderstand. edit: so hier ist es, flog noch irgendwo herum, bevor es der Server auf temp nach 3 Tagen löscht.
Moin, - Christian J. schrieb: > Alfons K. schrieb: >> Selbst die China-Klone und >> Fälschungen(*) (also die Chips) funktionieren in 99,99% der Fälle. > > Nein, tun sie nicht! Die mit den roten Punkten sind alle defekt gewesen! > Überall funktionierte I2C nicht! Was genau habe ich mir nicht die Mühe > gemacht, da meine Software da fehlerfrei ist. gewagte Aussage dass Deine Software fehlerfrei ist. Und die sechs Seiten Errata fuer die I2C-Implementierung des STM32F103 hast Du gelesen, verstanden und beruecksichtigt? Gruesse Th.
Jörg W. schrieb: > Nur mit eingebauten Pullups > mutiert I²C auch nach meiner Erfahrung schnell zum Glücksspiel. Die "eingebauten" sind meistens 10k. Auf den ADXL aber auch am Display. Mag für 5V laufen. Entweder man lötet die runter oder man setzt am Ende des Busses noch 2 x 5k. Komischerweise musste ich die 4x 10k PU an der SD Karte entfernen, mit denen lief es nicht, nur Müll. Alle weg, seitdem spielt das bis fast 8 Mhz hoch.
Thomas W. schrieb: > gewagte Aussage dass Deine Software fehlerfrei ist. Und die sechs Seiten > Errata fuer die I2C-Implementierung des STM32F103 hast Du gelesen, > verstanden und beruecksichtigt? Suche die Fehler. Und wenn du einen findest habe ich Unrecht und Du recht :-) Errata 1x reingeschaut... mehr aber auch nicht. Ist heftig, ja. Da ich eh keine Fehlerbehandlung durchführen kann (was soll das Board auch machen außer stehenbleiben, bis der WDT es rausreisst) führt alles in den HardFault Handler auf der nächsten Ebene. Komm... zerpflück es, ich halte das aus :-))) Das hier habe ich lange gesucht, und da gefunden. Das ist bis heute so. Da hat es lange gedauert bis der Groschen fiel mal da rein zu schauen :-( Description Conflict between the I2C2 SMBA signal (even if this function is not used) and SPI2_NSS in output mode. Conflict between the I2C2 SMBA signal (even if this function is not used) and USART3_CK. In these cases the I/O port pin PB12 is set to 1 by default if the I/O alternate function output is selected and I2C2 is clocked
Christian,
ich möchte mich mit unfreundlichen Kommentaren zurückhalten, weil ich
selbst sehe, wie sich manche hier wohl ihr Ego streicheln indem sie
andere anpflaumen, aber jedem von uns würde wohl ein wenig mehr Demut
gut bekommen.
Meine Software ist nachweislich besser als die Software von 99% meiner
Kollegen und ich würde niemals auch nur ansatzweise denken meine
Software sei "fehlerfrei" oder das auch nur behaupten.
Es ist schwierig Deine Software zu beurteilen ohne z.B. die Include
FIles zu sehen, aber alleine schon die Tatsache, dass Du das include
2-mal reinschlunzt spricht Bände.
Der I2C code sieht jetzt nicht sehr elaboriert aus, einige Kommentare
entsprechen nicht dem, was im Code dann steht...
GPIO_InitStruct.GPIO_Speed = GPIO_Speed_50MHz; // IO Speed,
nicht Baudrate, 2 Mhz reicht
Kurzum: Deine Programmierkenntnisse entsprechen so in etwa meinen
Elektronikkenntnissen. Also nicht vorhanden. ;-)
Ich habe hier eine einzige Pille (von ca. 40) die nicht tut. Aber die
wurde auch mit 10.2V bearbeitet...
Ich verwende zwar libopencm3 und FreeRTOS und kann mit HAL nicht viel
anfangen, aber gem. Referenz muss man das I2C Device erstmal ausschalten
bevor man am Konfigurationsregister rumknödelt.
i2c_peripheral_disable(I2C1); // disable
device
i2c_reset(I2C1); // reset I2C
I2C_CR1(I2C1) &= ~I2C_CR1_STOP; // clear
stop
i2c_set_speed(I2C1, i2c_speed_fm_400k, 36); // set I²C
to 400kHz, APB frequency 36MHz
etc. blah blah
und irgendwann dann ... als allerletztes:
i2c_peripheral_enable(I2C1); // after
everything is configured -> enable the peripheral
Bei Deinem Code sehe ich, dass Du das Ding erstmal enablest und dann gib
ihm...
???
Angehängte Dateien:
-
bluepill.png
280 KB
Christian J. schrieb: > Die "eingebauten" sind meistens 10k was erzählst du da? Die BP Boards haben keinerlei Pullups am I2C. Um genau zu sein kein MCU Pin auser dem D+ hat ein Pullup. Die Widerstände die ja auch auf deinem Foto zu sehen sind hängen an den Bootpins, am USB und an den Quarzen und den LEDs. Im Anhang ein Refernez Schematic so eines Boards
Thomas Z. schrieb: > was erzählst du da? Die BP Boards haben keinerlei Pullups am I2C. Aber die beteiligen Boards die daran angeschlossen sind. Die meisten solchen fertigen I2C Module haben per Default schon zweimal 10K Pullups drauf, das reicht schon dann dicke wenn man mehrere Module am I2C Bus betreibt. Auch das einzelne Modul funktioniert in der Regel schon einwandfrei mit niedrigen (100KHz) Datenraten.
hard werker schrieb: > Aber die beteiligen Boards die daran angeschlossen sind. Ob der TO allerdings seinen I2C Bus korrekt aufgebaut hat (Leitungsführung) kann man schon mal bezweifeln, denn das was an Software-Defiziten vorhanden ist kann bei der Hardware nur noch schlimmer sein. Siehe dazu auch meinen Kommentar: hard werker schrieb: > Ich hab dich hier ja schon öfters erlebt und du gehörst auch > zu der Sorte von Leuten die von ihrer Hardware alles fordern > ohne auf deren Befindlichkeit(en) einzugehen.
Alfons K. schrieb: > Bei Deinem Code sehe ich, dass Du das Ding erstmal enablest und dann gib > ihm... SPL ist nicht HAL und nicht libcm3. In SPL und HAL wird eine Struktur mit Werten gefüllt und der Init Funktion übergeben, und diese kümmert sich schon darum was zum Register setzen nötig ist. Das Peripheral selber muss erstmal eingeschaltet werden, sonst reagieren die Register nicht auf Schreibversuche. Der Kommentar war richtig, warum trotzdem auf 50MHz konfiguriert wird ist unbekannt. Der I2C kommt jedenfalls mit den langsameren Flanken aus, wie auch im Kommentar steht.
Angehängte Dateien:
-
CCR_STM32_ref781.png
36 KB
Johannes S. schrieb: > Das Peripheral selber muss erstmal eingeschaltet > werden, sonst reagieren die Register nicht auf Schreibversuche. Das sieht RM0008 - s.o. - aber anders.
Peripheral clock enable ist nicht I2C enable. Und das wird nach dem init ausgeführt. Wenn man schon über die Programmierkenntnisse anderer herzieht, dann sollte man selber etwas Ahnung haben.
Alfons K. schrieb: > Johannes S. schrieb: > >> Das Peripheral selber muss erstmal eingeschaltet >> werden, sonst reagieren die Register nicht auf Schreibversuche. > > Das sieht RM0008 - s.o. - aber anders. Gemeint war wohl der Takt fuer der Peripipheral...
Johannes S. schrieb: > Peripheral clock enable ist nicht I2C enable. > Und das wird nach dem init ausgeführt. Ja. > Wenn man schon über die Programmierkenntnisse anderer herzieht, dann > sollte man selber etwas Ahnung haben. He Leute ... in was für eine Community bin ich hier geraten? Ja, den ENABLE sehe ich auch. was ich nicht sehe, ist ein
1 | I2C_Cmd(I2Cx, DISABLE); |
vorher. vgl. z.B. http://mercury.pr.erau.edu/~siewerts/cec450/code/FreeRTOSExampleCode/Demo/Common/drivers/ST/STM32F10xFWLib/src/stm32f10x_i2c.c so wie es STM in den älteren Libs noch macht. In den neueren dann
1 | /* Disable the selected I2C peripheral to configure TRISE */
|
2 | I2Cx->CR1 &= CR1_PE_Reset; |
vgl. z.B. https://github.com/particle-iot-archived/core-common-lib/blob/master/STM32F10x_StdPeriph_Driver/src/stm32f10x_i2c.c Auch das sehe ich nirgends. Ich bin ja nun wahrlich keine Schneeflocke und finde ja diese neumodischen "Code of Conduct" bei vielen Projekten übertrieben, aber vielleicht wäre das ja mal was hier zur Eindämmung der Giftspuckerei.
Alfons K. schrieb: > Ich bin ja nun wahrlich keine Schneeflocke und finde ja diese > neumodischen "Code of Conduct" bei vielen Projekten übertrieben, aber > vielleicht wäre das ja mal was hier zur Eindämmung der Giftspuckerei. Darum lese ich auch nur noch mit derzeit.....
Johannes S. schrieb: > Der Kommentar war richtig, warum trotzdem auf 50MHz konfiguriert wird > ist unbekannt. Der I2C kommt jedenfalls mit den langsameren Flanken aus, > wie auch im Kommentar steht. Ich habe auf dem Oszi keine Veränderung gesehen, egal was man da einstellt. Und auch im Netz danach gesucht. Lässt du es weg spielt der Pin aber nicht. Dachte erst die Slew Rate würde damit eingestellt (EMV), vielleicht ein kleines R im Strang dazu gemogelt. Die Flanken haben alle Spikes im steigenden Ast (nicht bei i2C aber sonst an anderen Pins). Da gibt es aber wohl Ausarbeitungen drüber.
Alfons K. schrieb: > He Leute ... in was für eine Community bin ich hier geraten? ja sorry, da kommt ein Neuer und behauptet als erstes mal die anderen können nicht programmieren. Sehr nett. Alfons K. schrieb: > In den neueren dann > /* Disable the selected I2C peripheral to configure TRISE */ > I2Cx->CR1 &= CR1_PE_Reset; das passiert im I2C_init. https://github.com/particle-iot-archived/core-common-lib/blob/3cdaed3ca40949a466027942c4b253adebc2ccf0/STM32F10x_StdPeriph_Driver/src/stm32f10x_i2c.c#L222-L224 und das ist die SPL die der TO benutzt.
Johannes S. schrieb: > Alfons K. schrieb: >> He Leute ... in was für eine Community bin ich hier geraten? > > ja sorry, da kommt ein Neuer und behauptet als erstes mal die anderen > können nicht programmieren. Sehr nett. Ja genau. "Ein Neuer" - was erlaubt der sich. Der soll gefälligst ganz unten im lokalen Affenhügel anfangen - wie alle anderen Neuen auch. Gibt's hier auch Badges? Außerdem habe ich nicht behauptet, dass "die anderen" nicht programmieren können. Was ich aber schon behaupten könnte, dass zumindest "ein anderer" Probleme mit logischen Schlussfolgerungen hat. Also zum Thema: So wie es aussieht... Multiple überflüssige includes, Inhalt sieht man nicht. Muss man also glauben, dass da jemand den I2C mit 100kHz fahren will. Initialisierung des Masters wohl soweit erträglich. Ja, für 100kHz würden 2MHz reichen, aber wenn der TO meint das geht nicht, dann sind halt Zweifel angebracht. Ob man nun die "own address" auf 0x00 setzen muss oder nicht lasse ich mal als fraglich im Raum stehen. Prinzipiell sollte das nicht zum Tragen kommen (also könnte man es weglassen), oder man möchte eben keine I2C Adresse 0-7 oder 120-127 (dec.) definieren, weil diese special sind. Siehe I2C Referenz. Wenn man mal nämlich so eine Adresse auf den I2C Bus loslässt, kann es durchaus sein, dass sich irgendwelche Slaves erhängen. Dann ist vollkommen egal wie gut man den Master resetetetetetetet! Bzw. muss man dann ganz große Klimmzüge machen. Hey - ich habe ja nur die letzten Monate fast ausschliesslich an einer I2C Enterprise lib für den STM32 gearbeitet, aber vmtl. habe ich keine Ahnung. > und das ist die SPL die der TO benutzt. Ich habe zwar gesagt, dass ich diese Lib nicht (gut genug) kenne, aber gut, nehme ich irgendwie auch da alles zurück und behaupte das Gegenteil - oder auch nicht. Einen Disable macht die Lib im init, einen Enable aber nicht. Ja klar - warum nicht? Eigentlich kann es mir ja egal sein. Mein STM32 I2C funktioniert perfekt. Trotzdem würde ich nie behaupten der Code sei fehlerfrei. Das war eigentlich die Kernaussage.
Baldmann schrieb: > Sollte die Behauptung "BluePills sind tot." stimmen, sollte das sich in > den Bewertungen bei Ebay widerspiegeln. Es wird immer wieder von massenhaft gekauften Bewertungen berichtet.
Christian J. schrieb: > Ich flashe 82kb Code > Mit ca 40kb laufen die roten Boards Es hat wohl einen Grund, warum die Chips mal als RBT6 und mal als R8T6 beschriftet werden. Wenn die R8T6 mit merh als 64kB laufen, dann ist das Glück. Wenn sie nicht laufen, wäre das logischerweise das erste gewesen, was ich geprüft hätte.
Peter D. schrieb: > Vielleicht ist das Verify fehlerhaft, Einfach mal ein Katzenbild hochladen und wieder herunter laden.
Christian J. schrieb: > GIT kenne ich mich nicht mit aus, weiss nur dass es das gibt. Dann lerne es. Das Tool ist für Softwareentwickler wie der Seitenschneider in der Werkzeugkiste eines Handwerkers. Muss man einfach haben. http://stefanfrings.de/git/index.html
Stefan ⛄ F. schrieb: > Dann lerne es. Das Tool ist für Softwareentwickler wie der > Seitenschneider in der Werkzeugkiste eines Handwerkers. Muss man einfach > haben. Nö! Da ich keinen Cent damit verdiene, beruflich schon seit 15 Jahren keine Software mehr schreibe, niemand sonst meinen Code verwendet, weil ich mit der veralteten SPL arbeite und ich noch andere Hobbies habe, die mit vielen Menschen zusammen betrieben werden statt allein vor einem Rechner zu hocken, bleibt es wie es vor 10 Jahren auch schon war: Bevor ich rumfummel mache ich ein Backup für einen Tag und wenn das alles schief geht spiele ich das zurück.
Stefan ⛄ F. schrieb: > Christian J. schrieb: >> GIT kenne ich mich nicht mit aus, weiss nur dass es das gibt. > > Dann lerne es. Das Tool ist für Softwareentwickler wie der > Seitenschneider in der Werkzeugkiste eines Handwerkers. Muss man einfach > haben. Nö, muß man nicht. Man kann sowas betreiben, wenn man beim Programmieren sowas ähnliches ist wie beim Heimwerken die Youtube-Leute, die dort einen Kanal betreiben. Eben Leute mit erhöhtem Drang nach Selbstdarstellung (oder verkappte Professionelle). W.S.
Christian J. schrieb: > Da ich keinen Cent damit verdiene, beruflich schon seit 15 Jahren > keine Software mehr schreibe, niemand sonst meinen Code verwendet, Bei Git geht es nicht darum, Quellcode zu veröffentlichen. Das verwechselst du mit GitLab. Git ist ein Tool, mit dem man Backups macht, und Änderungen nachvollziehbar dokumentiert. Das Tool mach auch für dich ganz alleine Sinn. Du brauchst dazu keinen Server (nicht einmal lokal). Du machst ja jetzt schon regelmäßig Schnappschüsse von deinen Dateien. Git baut auf diesem Prinzip auf, und setzt mächtige Hilfsmittel oben drauf, mit denen du deine Schnappschüsse vergleichen kannst. Du kannst nachher zu jeder Datei oder gar einzelnen Zeilen die Frage stellen: Wann ich hier was geändert und warum? Also genau das, was du jetzt gerade brauchst. Dazu kommt, dass fast jede Entwicklungsumgebung Git integriert hat, so dass man weniger Befehle eintippen muss. Es hilft aber trotzdem, die Basics erstmal auf der Kommandozeile kennen zu lernen. Schau dir meinen Aufsatz dazu doch mal an, so groß ist der nicht, dass man sich davor scheuen müsste.
W.S. schrieb: > Nö, muß man nicht. > Man kann sowas betreiben Wie gesagt, es geht weder ums Veröffentlichen noch um Server. > Eben Leute mit erhöhtem Drang nach Selbstdarstellung Ich merke, dass du keine Ahnung hast. Dann kennst du wohl CVS, Subversion und Mercurial auch nicht. Werde mal wach, oder bist du schon im Ruhestand?
W.S. schrieb: > Youtube-Leute, die dort einen Kanal > betreiben. Mit dem Unterschied, dass Youtube mir jeden Monat rund 90 Euro überweist von den Werbeeinnahmen und mein Sponsor mich kostenlos mit dem neuesten Plunder versorgt, den man zum Überleben im Wald so braucht :-)
Ja, git, debugger und IDE, völlig überbewertet dieses neumodische Zeug. Dinosaurier halt.
Stefan ⛄ F. schrieb: > Das verwechselst du mit GitLab. Sorry, jetzt habe ich auch Namen verwechselt, ich meinte GitHub.
Es gibt beide als öffentliche Hosts, gitlab kann man auch als kostenlose Variante selber hosten. Muss man für den Anfang nicht, ist aber Dank fertiger Container auch kein Hexenwerk.
Wie gesagt galt meine Empfehlung allerdings nur Git ohne Server, also auch kein GitLab und kein GitHub.
bin gerade über einen Verkäufer gestoßen bei dem kann man zw. STM und CH(µUSB und USB-C) entscheiden mach 2€ unterschied. Es steht auch einigen zu den Tools und zu den Gemeinsamkeiten/Unterschieden zw. STM und CH dabei. https://www.aliexpress.com/item/1005002372303913.html
Stefan ⛄ F. schrieb: > Dann lerne es. Das Tool ist für Softwareentwickler wie der > Seitenschneider in der Werkzeugkiste eines Handwerkers. Muss man einfach > haben. +1
Stefan ⛄ F. schrieb: > Stefan ⛄ F. schrieb: >> Das verwechselst du mit GitLab. > > Sorry, jetzt habe ich auch Namen verwechselt, ich meinte GitHub. Sag mal Stefan, ich lese grad Deine Seite durch (tolles Buch übrigens!) für den ESP8266, den ich jetzt mit diesen Mini Displays vorliegen habe. Ich habe mit dem ESP8266 NodemCu eine sehr komfortable Wetterstation (JSON Import) aufgebaut die seit vielen Monaten ununterbrochen durchläuft. Du warnst vor Heap Funktionen wie string. Warum? Ich benutze die nur, kreuz und quer, hunderte um die HTTP Message zu basteln, die ich an den Server sende. Das spielt doch prima. Gibt keinen Grund die nicht zu verwenden. Ansonsten... da der ESP8266 nur mir viel Mühe auf https zu kriegen ist sehe ich diesen Chip als Spielzeug an, da heute 99,9% aller Webseiten SSL kodiert sind und Zertifikate erwarten. Mehr als Wlan Thermometer, Wetterabfragen und Blumengießen habe ich damit noch nicht gesehen.
Christian J. schrieb: > Sag mal Stefan, Wenn Du Fragen an Stefan hast, dann mail ihn doch einfach oder mach einen neuen Thread dafür auf. Es ist schlechter Stil, einen Thread zu kapern (auch wenn es der eigene ist). Das hat mit dem Ursprungsthema wirklich nichts mehr zu tun.
:
Bearbeitet durch User
Christian J. schrieb: > Ansonsten... da der ESP8266 nur mir viel Mühe auf https zu kriegen ist > sehe ich diesen Chip als Spielzeug an, da heute 99,9% aller Webseiten > SSL kodiert sind und Zertifikate erwarten. Mehr als Wlan Thermometer, > Wetterabfragen und Blumengießen habe ich damit noch nicht gesehen. Du kennst z.B. Tasmota? Kein https ist aber in der Tat ein gewaltiges Problem. Das der Fischreiher sich hier auf dem Land in meine Steckdosen hackt, ist zum Glück eher unwahrscheinlich.
Christian J. schrieb: > Und darum war der Reset blockiert und zwar alle Resets > klappen dann nicht mehr. Dass sowas geht dachte ich nicht aber nachher > ist man ja immer schlauer. Naja, im Schaltplan ist das ja eindeutig zu sehen. Alle Resets gehen von hinten durch die Brust ins Auge, d.h. über den externen Resetpin. Schon der oft benutzte Resetkondensator kann das aushebeln. Wer denkt sich denn blos so einen Unsinn aus. Für mich ein Grund, solche MCs auf keinen Fall zu kaufen. Die internen Resetquellen müssen immer direkt auf die CPU gehen. Bei zuverlässigen MCs darf der Resetpin immer nur ein Eingang sein. Will man Peripherie resetten, kann man das ja einfach über einen IO-Pin machen.
Christian J. schrieb: > Du warnst vor Heap Funktionen wie string. Warum? Habe ich doch auf der Seite begründet, mit Links zu weiterführenden Artikeln. Wir können das gerne in einem eigenen Thread diskutieren, hier ist es unpassend.
Stefan ⛄ F. schrieb: > Wir können das gerne in einem eigenen Thread diskutieren, hier > ist es unpassend. Einverstanden, wurde etwas später :-) Und ab heute bin ich eh ne Woche im Urlaub.
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.