Ein Kollege hat sich mit einer SPI-Implementierung herum- geschlagen. Es war ihm nicht möglich auf eine ausgesendete Adresse eine Antwort (Ack, aktiv low) zu bekommen. Ich blickte ihm über die Schulter aufs Oszilloskop und sah dass der Slave beim neunten Bit antworten wollte aber der Pegel nur zu ca. einem Drittel von 3.3V herunterkam. Für mich lag der Verdacht nahe dass ein anderer Teilnehmer auf dem Bus den Pegel auf 3.3V halten wollte, oder extrem starke Pullups dagegen hielten. Beides war jedoch in der betreffenden Schaltung nicht der Fall. Wie sich dann herausstellte müssen die Pins der benutzten I2C-Schnittstelle nicht nur auf Alternate Function gesetzt werden sondern auch deren prinzipielle Ein-/Ausgangsfunktion auf Open Drain. Ist das nicht der Fall so kämpft die SPI- Maschine im Pegel gegen den Ausgangstreiber des Pins. Hätten sie's gewusst? Ein STM32F407 kann sich am Pin selbst kurzschliessen? Selbst das Manual gibt sich zu diesem Thema sehr schmal-lippig .... Ich bin auf dieses Problem noch nicht gestossen da ich sehr gerne meine Soft-I2C-Implemetierung verwende die mir freie Wahl der Pins ermöglicht. Ich liebe es. Ich sehe dem Shitstorm entgegen ...
STM Apprentice schrieb: > Ein Kollege hat sich mit einer SPI-Implementierung Korrektur: mit einer I2C-Implementierung
Natürlich müssen alle beteiligten Anschlüsse bei I²C Open-Drain/Collector sein - was denn sonst? I²C nicht verstanden? STM Apprentice schrieb: > Ich sehe dem Shitstorm entgegen ... zu Recht!
Harry L. schrieb: > Natürlich müssen alle beteiligten Anschlüsse bei I²C > Open-Drain/Collector sein - was denn sonst? Bei anderen alternative Funktionen muss das ja auch nicht gemacht werden .... angeblich bei Atmel ARMs funktioniert I2C auf die "erwartete" Art, ohne Alternate Function. Harry L. schrieb: > I²C nicht verstanden? Ähmmmm, ich berichte von einem Kollegen, verstanden?
STM Apprentice schrieb: > Hätten sie's gewusst? Ja, das steht nämlich klar im Referenzhandbuch (jedenfalls beim STM32F103).
Harry L. schrieb: > Natürlich müssen alle beteiligten Anschlüsse bei I²C > Open-Drain/Collector sein - was denn sonst? Du findest es also in Ordnung dass sich ein Chip selbst ohne äussere Beschaltung in Knie schiessen kann/darf.
STM Apprentice schrieb: > angeblich bei Atmel ARMs funktioniert > I2C auf die "erwartete" Art, ohne Alternate Function. Ja und? Ein ST ist nicht Atmel. Jeder Hersteller kocht seine eigene Suppe. Nur der Kern ist von ARM vorgegeben, aber auch dort gibt es viel Spielraum für Varianten.
STM Apprentice schrieb: > Wie sich dann herausstellte müssen die Pins der benutzten > I2C-Schnittstelle nicht nur auf Alternate Function gesetzt > werden sondern auch deren prinzipielle Ein-/Ausgangsfunktion > auf Open Drain. Ist das nicht der Fall so kämpft die SPI- > Maschine im Pegel gegen den Ausgangstreiber des Pins. Ich habe gerade das Gefühl dass dein Kollege die adaptierte HAL für Arduino verwendet hat. Da hat einer ein Problem gehabt ein Sensor einzulesen.
STM Apprentice schrieb: > in Knie Ist es nicht eher der Programmierer, welcher sich mit einer defekten/unvollständigen Konfiguration eine Frikadelle ans Knie nagelt?
STM Apprentice schrieb: > Wie sich dann herausstellte müssen die Pins der benutzten > I2C-Schnittstelle nicht nur auf Alternate Function gesetzt > werden sondern auch deren prinzipielle Ein-/Ausgangsfunktion > auf Open Drain. Ich wette eine Tüte Gummibärchen daß das im Reference Manual steht.
Alex W. schrieb: > Ich habe gerade das Gefühl dass dein Kollege die adaptierte HAL für > Arduino verwendet hat. Dein Gefühl täuscht dich. Mein Kollege ist Liebhaber der Bare-Metal Programmierung. Und war auch sehr überrascht über die Möglichkeit sich selbst ins Knie zu schiessen.
Arduino Fanboy D. schrieb: > STM Apprentice schrieb: >> in Knie > > Ist es nicht eher der Programmierer, welcher sich mit einer > defekten/unvollständigen Konfiguration eine Frikadelle ans Knie nagelt? So sehe ich das auch. Der Chip tut nur das, was man ihm befohlen hat. Würde er wie ein bockiger Esel sagen "nö, das mache ich jetzt nicht, weil ich es nicht für sinnvoll halte", dann hätte ich keinen Spaß mit dieser Technik. Das ist auch kein neues Problem. Bei C64 konnten böse Programme einen Kurzschluss in der Tasten-Matrix auslösen und so beträchtlichen Schaden verursachen. Wer das nicht will, muss die Schaltung deppensicher auslegen.
Nächstes Thema bitte. Ist doch logisch, dass I²C Pins kein Push-Pull sind.
STM Apprentice schrieb: > Alex W. schrieb: >> Ich habe gerade das Gefühl dass dein Kollege die adaptierte HAL für >> Arduino verwendet hat. > > Dein Gefühl täuscht dich. Mein Kollege ist Liebhaber der > Bare-Metal Programmierung. Und war auch sehr überrascht über > die Möglichkeit sich selbst ins Knie zu schiessen. Ok, dann habe ich mich da geirrt! Ich habe nämlich selbst schon dieses Problem lösen müssen. Ich komm aus der AVR-Ecke und habe lange gebraucht das zu verstehen bzw. im Datenblatt zu finden ;-)
STM Apprentice schrieb: > Du findest es also in Ordnung dass sich ein Chip selbst > ohne äussere Beschaltung in Knie schiessen kann/darf. Ohne äußere Beschaltung hätte es keine Kollision mit dem externen I2C-Slave gegeben, daher ist dieser Einwand nicht nachvollziehbar.
Bernd K. schrieb: > daher ist dieser Einwand nicht nachvollziehbar. Macht wohl nicht viel Sinn einen I2C Master ohne Slave zu betreiben.
STM Apprentice schrieb: > Mein Kollege ist Liebhaber der > Bare-Metal Programmierung. Und war auch sehr überrascht über > die Möglichkeit sich selbst ins Knie zu schiessen. Dein Kollege ist Bare-Metal Liebhaber und wußte nicht daß man sich ins Knie schießen kann? Ich bin einigermaßen überrascht. Daß man sich wahlweise auch in den Fuß schießen kann wußte er aber wenigstens, oder?
:
Bearbeitet durch User
STM Apprentice schrieb: > Bernd K. schrieb: >> daher ist dieser Einwand nicht nachvollziehbar. > > Macht wohl nicht viel Sinn einen I2C Master ohne Slave > zu betreiben. Nur bist DU ja derjenige der ständig auf die Formulierung "ohne äussere Beschaltung" beharrt. Natürlich ist das Unsinn. Aber dein Unsinn.
Cyblord -. schrieb: > Natürlich ist das Unsinn. Aber dein Unsinn. Ok, dann habe ich mich hier falsch ausgedrückt.
STM Apprentice schrieb: > Bernd K. schrieb: >> daher ist dieser Einwand nicht nachvollziehbar. > > Macht wohl nicht viel Sinn einen I2C Master ohne Slave > zu betreiben. Dann hat er sich aber auch nicht selbst ins Knie geschossen sondern ins Knie des unschuldigen Slaves am anderen Ende.
Die STM32 können sich dank PLL auch selbst übertakten. Man kann die Flash Wait States zu kurz einstellen und die Frequenz diverser Peripherie-Module und auch der Prozessor-Busse zu hoch. Man kann die Performance-Modi einschalten obwohl nicht genug Spannung anliegt. Und man kann Peripheriemodule inkonsistent zu den GPIO-Einstellungen konfigurieren. In all diesen (und vielen weiteren) Fällen funktionieren die Controller nicht richtig. Für narrensichere Schutzlogik wird kein Geld ausgegeben...
STM Apprentice schrieb: > Hätten sie's gewusst? Ein STM32F407 kann sich am Pin selbst > kurzschliessen? Selbst das Manual gibt sich zu diesem Thema > sehr schmal-lippig .... Erstens hat er ja nicht sich kurzgeschlossen, sondern der Slave mit dem Master. Zweitens ist im RM schon klar beschrieben, dass die Konfiguration der GPIOs unabhängig von der Auswahl als "Alternate Function" ist, z. B. zählt Tabelle 35 auch und gerade bei AF die diversen Kombinationen PP, PP+UP ... und auch OSPEEDR auf. Das ist schon eine andere Philosophie als etwa bei NXP, wo z. B. GPIOs kein OD kennen, und I2C-Pins nur als solche, nicht aber als GPIO verwendbar sind. Muss man nicht mögen, ist aber bei allen STM32 (bis auf F1) weitgehend konsequent durchgehalten (naja, die Oszillator-Pins sind eine andere Sache) und sollte daher jedem vertraut sein, auch wenn man es natürlich mal übersehen kann. Ab MP1 wird's dann zwar etwas unschöner, aber das ist technisch wohl unvermeidlich ...
Hallo A. B. schrieb: > STM Apprentice schrieb: > Muss man nicht mögen, ist aber bei allen STM32 (bis auf F1) weitgehend > konsequent durchgehalten (naja, die Oszillator-Pins sind eine andere > Sache) und sollte daher jedem vertraut sein, auch wenn man es natürlich > mal übersehen kann. Ab MP1 wird's dann zwar etwas unschöner, aber das > ist technisch wohl unvermeidlich ... Wo gibt es zum MP1 bereits solche "intimen" Daten? Auf der Website ist nur ein allgemeine DS, jedoch kein RM zu finden. Die Errats sind aber schon online ;-) Gruß
Das ist doch durchgängig bei allen GPIO so. Für jedes Peripheriemodul musst Du zusätzlich auch noch die entsprechenden Pins konfigurieren. Der ADC-Pin muss als Analog-Input konfiguriert werden, der PWM-Ausgang als Output,... Warum sollte das gerade bei I2C anders sein? Und auch wenn das bei I2C vielleicht etwas hergeholt ist - es gibt immer wieder Vorteile, dass Du die Konfiguration der Pins komplett selbst in der Hand hast. Bei I2C könntest Du z.B. den Pin (zum Debuggen) bewusst Push-Pull konfigurieren und die open-drain Funktion durch eine Diode am Ausgang erreichen, um am Oszi unterscheiden zu können, welche Pegel von welchem Device erzeugt werden. Gruß, Stefan
Mit CubeMX und HAL wäre das nicht passiert, der macht das von selbst. ;)
pegel schrieb: > Mit CubeMX und HAL wäre das nicht passiert, der macht das von selbst. ;) Glaube ich nicht. Auch bei CubeMX muss man die I/O Pins ausdrücklich konfigurieren, bevor man sie benutzt.
Nein, habe es extra probiert, bevor ich das behauptet habe.
Stefanus F. schrieb: > pegel schrieb: >> Mit CubeMX und HAL wäre das nicht passiert, der macht das von selbst. ;) > > Glaube ich nicht. Auch bei CubeMX muss man die I/O Pins ausdrücklich > konfigurieren, bevor man sie benutzt. Vielleicht sollte man über die Produkte Bescheid wissen über die man regelmäßig herzieht? ;)
pegel schrieb: > Mit CubeMX und HAL wäre das nicht passiert, der macht das von > selbst. ;) Kann man diesen Automatismus wenigstens konfigurieren, nur für den Fall daß man es doch mal anders braucht? Oder streicht die HAL hier einfach die Featureliste gnadenlos auf einen kleinen gemeinsamen Nenner zusammen?
Ja ihr solltet euch besser mit dem HAL auskennen bevor ihr Schlüsse zieht. Der CubeMX generiert extra Code um die I2C Pins zu initialisieren. Das ist dann die "HAL_I2C_MspInit" welche von dem HAL Treiber als weakref aufgerufen wird. Dann noch schön mit if Abfrage für welchen I2C das denn nun ist ... ekelhaft.
1 | void HAL_I2C_MspInit(I2C_HandleTypeDef* hi2c) |
2 | {
|
3 | |
4 | GPIO_InitTypeDef GPIO_InitStruct; |
5 | if(hi2c->Instance==I2C1) |
6 | {
|
7 | /* USER CODE BEGIN I2C1_MspInit 0 */
|
8 | |
9 | /* USER CODE END I2C1_MspInit 0 */
|
10 | |
11 | /**I2C1 GPIO Configuration
|
12 | PB8 ------> I2C1_SCL
|
13 | PB9 ------> I2C1_SDA
|
14 | */
|
15 | GPIO_InitStruct.Pin = GPIO_PIN_8|GPIO_PIN_9; |
16 | GPIO_InitStruct.Mode = GPIO_MODE_AF_OD; |
17 | GPIO_InitStruct.Pull = GPIO_PULLUP; |
18 | GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_VERY_HIGH; |
19 | GPIO_InitStruct.Alternate = GPIO_AF4_I2C1; |
20 | HAL_GPIO_Init(GPIOB, &GPIO_InitStruct); |
21 | |
22 | /* Peripheral clock enable */
|
23 | __HAL_RCC_I2C1_CLK_ENABLE(); |
24 | /* USER CODE BEGIN I2C1_MspInit 1 */
|
25 | |
26 | /* USER CODE END I2C1_MspInit 1 */
|
27 | }
|
28 | |
29 | }
|
Schon lustig, dass die HAL verfechter das nicht wissen. (Ich bin Registertrommler) Der I2C HAL Init ist dann extra:
1 | /* I2C1 init function */
|
2 | static void MX_I2C1_Init(void) |
3 | {
|
4 | |
5 | hi2c1.Instance = I2C1; |
6 | hi2c1.Init.ClockSpeed = 100000; |
7 | hi2c1.Init.DutyCycle = I2C_DUTYCYCLE_2; |
8 | hi2c1.Init.OwnAddress1 = 0; |
9 | hi2c1.Init.AddressingMode = I2C_ADDRESSINGMODE_7BIT; |
10 | hi2c1.Init.DualAddressMode = I2C_DUALADDRESS_DISABLE; |
11 | hi2c1.Init.OwnAddress2 = 0; |
12 | hi2c1.Init.GeneralCallMode = I2C_GENERALCALL_DISABLE; |
13 | hi2c1.Init.NoStretchMode = I2C_NOSTRETCH_DISABLE; |
14 | if (HAL_I2C_Init(&hi2c1) != HAL_OK) |
15 | {
|
16 | _Error_Handler(__FILE__, __LINE__); |
17 | }
|
18 | |
19 | }
|
STM32MP1 liebäugler schrieb: > Wo gibt es zum MP1 bereits solche "intimen" Daten? Auf der Website ist > nur ein allgemeine DS, jedoch kein RM zu finden. Die Errats sind aber > schon online ;-) https://www.st.com/resource/en/reference_manual/dm00327659.pdf ist RM0436. Die anderen beiden sind zwar noch nicht da, aber die beziehen sich ohnehin nur auf die abgespeckten Varianten. Schon seit ca. 2 Tagen da, pünktlich zur EW. Aber die braucht man auch allein zum Überfliegen der über 4000 Seiten ... Viele Peripheriemodule sind zwar nicht "neu", sondern im Gegenteil alte Bekannte (inkl. Errata), aber die Tücke steckt im Detail, insbes. die diversen Betriebsspannungen und die zugehörigen Logikpegel für RAM, Flash ...
STM Apprentice schrieb: > Dein Gefühl täuscht dich. Mein Kollege ist Liebhaber der > Bare-Metal Programmierung. Und war auch sehr überrascht über > die Möglichkeit sich selbst ins Knie zu schiessen. Hoffentlich war er positiv überrascht!
A. B. schrieb: > STM32MP1 liebäugler schrieb: >> Wo gibt es zum MP1 bereits solche "intimen" Daten? Auf der Website ist >> nur ein allgemeine DS, jedoch kein RM zu finden. Die Errats sind aber >> schon online ;-) > > https://www.st.com/resource/en/reference_manual/dm00327659.pdf ist > RM0436. > > Die anderen beiden sind zwar noch nicht da, aber die beziehen sich > ohnehin nur auf die abgespeckten Varianten. > > Schon seit ca. 2 Tagen da, pünktlich zur EW. Aber die braucht man auch > allein zum Überfliegen der über 4000 Seiten ... Viele Peripheriemodule > sind zwar nicht "neu", sondern im Gegenteil alte Bekannte (inkl. > Errata), aber die Tücke steckt im Detail, insbes. die diversen > Betriebsspannungen und die zugehörigen Logikpegel für RAM, Flash ... Da war ab jemand fleissig bei ST. Respekt. Ich bin gespannt wie sich die MP1 gegen die i.MX sowie Sitaras schlagen. Aus Sicht der SW-Entwickler finde ich die HSEM (HW-Semaphor) und IPCC (inter processor communication controller) sehr interessant. Mit einer 2. Eth-MAC (10/100BT wäre ausreichend) hätte im Zusammenhang mit dem CM4 so manche Echtzeit-Ethernet Anbindung (EtherCAT, Profinet ...) elegant realisiert werden können. Bis das Ding bootet und das OS sich auf den verschiedenen Cores breit gemacht hat, ist einiges zu konfigurieren und parametrieren (wenn man nicht nur Linux verwendet). Es gibt viel zu tun! Gruß
Ich hatte wenn ich mich recht erinnere mit dem F103 schon ein ähnliches, wenn auch quasi umgekehrtes Problem. Wenn man den F103 als SPI-Master mit Hardware-NSS konfiguriert, ist der NSS-Pin automatisch als Open-Drain konfiguriert und wenn man dann den Pullup "vergisst" (weil man eigentlich Push-Pull konfiguriert hat) bekommt man diese Effekte wo eine Schaltung durch "Hand auflegen" funktioniert und sonst eben nicht. Hat mich auch schon ein paar graue Haare gekostet.
STM32MP1 liebäugler schrieb: > Ich bin gespannt wie sich die > MP1 gegen die i.MX sowie Sitaras schlagen. Die sind am unteren Ende der üblichen Applikationsprozessoren angesiedelt. Kategorie i.MX6 UL oder so, etwas über den SAMA5. Sieht man schon an den Features, nur 100Mbit Ethernet, nur 16Bit DDR3-Interface und nur 2 kleine vergleichsweise "langsame" Kerne. Aber das macht sie nicht uninteressanter. Sie sind nämlich trotzdem schnell genug, dass Linux nicht nur darauf läuft, sondern dass man damit auch etwas anfangen kann. Die Kombination aus Echzeit Cortex-M4, Linux-Prozessor und vernünftigem RAM macht Sinn. Dazu kommen HDMI, LCD-Interface CSI und Grafikbeschleuniger. Freu dich aber nicht zu früh, vermutlich benötigt man für das Teil einen PMIC und, sagen wir mal, Leiterplattendesign für Fortgeschrittene. Das DDR3-Layout ist nicht mehr mit der freien Eagle-Version machbar, und BGA ist das alles sowieso. Bleibt für Bastler auf SOMs zu hoffen. Ist zwar noch nichts angekündigt, aber wenn die Teile auch nur ein bischen auf dem Markt ankommen wird es sie früher oder später geben.
@soso Also ich hab da ein GBIT MAC gesehen im RefMan ;)
Bernd K. schrieb: > Kann man diesen Automatismus wenigstens konfigurieren Es sind sinnvolle Vorgabe Werte, die natürlich im Auswahl Menü verändert werden können. Ausserdem ist es nicht verboten in den User Bereichen die beliebten Register Befehle zu benutzen. Ich finde schon, dass das CubeMX/HAL Gespann inzwischen für neue Projekte brauchbar ist. Man kann sogar etwas lernen, wenn die Einstellungen in CubeMX durchgeht. Das sollte man sich auch grundsätzlich angewöhnen, da der Aufwand dafür recht überschaubar ist. Bin allerdings kein Profi Programmierer, der seine eigenen Code Stücke seit Jahren pflegt.
STM32MP1 liebäugler schrieb: > HSEM (HW-Semaphor) Welchen Vorteil bieten die über die Load/Store Exclusive und Supervisor-Mechanismen des Cortex-A-Kerns, mit welchen man normalerweise seine Semaphoren programmiert?
Mw E. schrieb: > @soso > Also ich hab da ein GBIT MAC gesehen im RefMan ;) Hast recht, das Evalbord hat GBIt: https://www.st.com/en/evaluation-tools/stm32mp157a-dk1.html Hab ich wohl übersehen. Trotzdem. Meine persönlich Einordnung am unteren Ende der Applikationsprozessoren bleibt wie sie ist. Was ja nichts negatives ist. Ich denke, wenn ST ernsthaft in diesen Bereich einsteigen will, wird sicher noch mehr kommen, und die kleineren Kerne haben auch entscheidende Vorteile: Beispielsweise brauchts keinen Kühler. Ohne einen Kühler geht z.B. beim i.MX6 Quad nicht mehr viel, zumindest wenn man ihn voll auslastet. Interessant wäre, wo die 3D-Grafik einzuordnen ist.
Dr. Sommer schrieb: > STM32MP1 liebäugler schrieb: >> HSEM (HW-Semaphor) > > Welchen Vorteil bieten die über die Load/Store Exclusive und > Supervisor-Mechanismen des Cortex-A-Kerns, mit welchen man normalerweise > seine Semaphoren programmiert? Ich dachte da echer an den M4 im Gespann. Der soll mit den dicken A7 ebenfalls kommunizieren. Da wirds dann eher nichts mit "Load/Store Exclusive und Supervisor-Mechanismen"? Bin aber noch nicht ganz durch, durch die über 4000 Seiten Doku ;-)
STM32MP1 liebäugler schrieb: > Da wirds dann eher nichts mit "Load/Store > Exclusive und Supervisor-Mechanismen"? Hmm, wieso? Der M4 kennt auch LDREX/STREX und ebenso den Supervisor-Mode, kann also auch (einfache) RTOS ausführen. Vielleicht hat der keinen globalen Monitor. Schließlich war der M4 nie für Multicore-Systeme gedacht und das sind immer herstellerspezifische Konstrukte...
Dr. Sommer schrieb: > Hmm, wieso? Der M4 kennt auch LDREX/STREX und ebenso den > Supervisor-Mode, kann also auch (einfache) RTOS ausführen. > > Vielleicht hat der keinen globalen Monitor. Schließlich war der M4 nie > für Multicore-Systeme gedacht und das sind immer herstellerspezifische > Konstrukte... Müsste er hierzu nicht eine Verbindung zwischen dem A7-Cluster und dem M4 geben? Beide können ja gleichzeitig auf einen kritischen Bereich zugreifen (identischer Adressraum). Da sollte der Andere schon mitbekommen, dass der Eine gerade mit LDREX einen Lock angefordert hat. Ich habe mir nochmals den HSEM und den IPCC im RM des STM32MP1 angesehen. Wenn ich das richtig interpretiere, funktionieren die Blöcke hier nur zwischen den beiden A7-Kernen. Hier würde doch LDREX/STREX funktionieren? Weshalb dann die zusätzliche Peripherie? Ich frage mich nun, wie man dann locks zwischen den A7 und dem M4 implementiert könnte.
STM32MP1 liebäugler schrieb: > Müsste er hierzu nicht eine Verbindung zwischen dem A7-Cluster und dem > M4 geben Ja. Der Atomic Monitor oder wie das Teil hieß. STM32MP1 liebäugler schrieb: > Hier würde doch LDREX/STREX funktionieren? Ja. Die ARM Multiprocessing Architektur soll ja schließlich ohne Hersteller spezifische Erweiterungen auskommen. STM32MP1 liebäugler schrieb: > Weshalb dann die zusätzliche Peripherie? Das ist die Frage...
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.