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 ...
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?
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.
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.
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?
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.
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
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.
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
voidHAL_I2C_MspInit(I2C_HandleTypeDef*hi2c)
2
{
3
4
GPIO_InitTypeDefGPIO_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:
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.
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...
