STM32 I2C direkt über die Register

[Werner (Gast)]

Hallo,

ich versuche mit einem STM32F030 das I2C Interface direkt über die 
Register zu bedienen. Diese unzähligen Arten von HALs (mit 
Unterversionen) etc. finde ich sehr frustrierend, das ist unfassbares 
Chaos.

Zu der Registervariante, so versuche ich es derzeit:

#define PIN_SCL 10 //PB10
#define PIN_SDA 11 //PB11

//GPIOA und B aktivieren
RCC->AHBENR |= RCC_AHBENR_GPIOAEN | RCC_AHBENR_GPIOBEN;
//I2C aktivieren
RCC->APB1ENR |= RCC_APB1ENR_I2C1EN;

GPIOB->MODER |= 2 << (PIN_SDA<<1) ) | 2 << (PIN_SCL<<1); //alternate function
GPIOB->OTYPER |=  1 << (PIN_SDA << 1) | 1 << (PIN_SCL << 1); //open drain

GPIOB->AFR[PIN_SDA / 8] |= GPIO_AF1_I2C1 << ((PIN_SDA % 8) * 4); //AF1
GPIOB->AFR[PIN_SCL / 8] |= GPIO_AF1_I2C1 << ((PIN_SCL % 8) * 4); //AF1

//I2C reset
RCC->APB1RSTR |= RCC_APB1RSTR_I2C1RST;
RCC->APB1RSTR &= ~(RCC_APB1RSTR_I2C1RST);

I2C1->TIMINGR = 0x13 << 0 | 0xF << 8 | 0x2 << 16 | 0x4 << 20 | 0xB << 28;

//enable I2C
I2C1->CR1 |= I2C_CR1_PE;

//send 1 byte to address 0x90
I2C1->CR2 = I2C_CR2_START | 0x90 | 1<<16 | I2C_CR2_AUTOEND;
I2C1->TXDR = 0x55;

Es kommt nichts aus dem Chip, die beiden Leitungen bleiben auf High

Weiß jemand was fehlt?

Werner

[pegel (Gast)]

Ich habe kurz in CubeMX nachgesehen, PB10 und PB11 gehören eigentlich zu
I2C2.

[Dr. Sommer (Gast)]

Werner schrieb:
> GPIOB->OTYPER |=  1 << (PIN_SDA << 1) | 1 << (PIN_SCL << 1); //open
> drain
die OTYPE Felder sind nur 1 bit lang, daher muss das

GPIOB->OTYPER |=  1 << (PIN_SDA) | 1 << (PIN_SCL); //open drain

sein.

[Werner (Gast)]

Danke für die Antworten,

>PB10 und PB11 gehören eigentlich zu I2C2.
Habe nochmal nachgesehen, tatsächlich, im Datenblatt stehen zwar beide 
Ports, aber jeweils mit Fußnoten, die sollte man auch lesen

>die OTYPE Felder sind nur 1 bit lang, daher muss das
na klar richtig :-(

Habe mir mal noch 3 Macros geschrieben, dann ist das weniger 
fehlerträchtig:

#define MODER_PIN(x, y) ((x & 0x03) << ((y) << 1))
#define OTYPER_PIN(x, y) (((x >> 4) & 0x01) << (y))
#define OSPEEDR_PIN(x, y) ((x) << ((y) << 1))

GPIOB->MODER |= MODER_PIN(GPIO_MODE_AF_OD, PIN_SDA) | MODER_PIN(GPIO_MODE_AF_OD, PIN_SCL);
  GPIOB->OTYPER |=  OTYPER_PIN(GPIO_MODE_AF_OD, PIN_SDA) | OTYPER_PIN(GPIO_MODE_AF_OD, PIN_SCL);
  GPIOB->OSPEEDR |= OSPEEDR_PIN(GPIO_SPEED_HIGH, PIN_SDA) | OSPEEDR_PIN(GPIO_SPEED_HIGH, PIN_SCL);

Nun tut's also herzlichen Danke ihr beiden!

Werner

[Dr. Sommer (Gast)]

Werner schrieb:
> Habe mir mal noch 3 Macros geschrieben, dann ist das weniger
> fehlerträchtig:
> #define MODER_PIN(x, y) ((x & 0x03) << ((y) << 1))
> #define OTYPER_PIN(x, y) (((x >> 4) & 0x01) << (y))
> #define OSPEEDR_PIN(x, y) ((x) << ((y) << 1))

Ich würde dir raten das zu verbessern: Bei Makros gehören Konsequent 
Klammern um alle Parameter (fehlt hier bei x). Das "(y) << 1" ist für 
den Leser etwas verwirrend, schreib doch einfach "(y) * 2", das wird ja 
eh wegoptimiert. Außerdem würde ich allgemein kein Makro, sondern eine 
Funktion nehmen:

inline uint32_t MODER_PIN (uint8_t mode, uint8_t pin) {
  return (x & 3) << (2 * y);
}

Ist gleich viel lesbarer, sicherer, und genauso effizient (wird 
wegoptimiert).

[Dr. Sommer (Gast)]

Und natürlich sofort falsch gemacht, ich meinte:

inline uint32_t MODER_PIN (uint8_t mode, uint8_t pin) {
  return (((uint32_t) mode) & 3) << (2 * pin);
}

Oder noch besser:

inline uint32_t MODER_PIN (uint8_t mode, uint8_t pin) {
  assert ((mode & 3) == mode);
  return ((uint32_t) mode) << (2 * pin);
}

[Werner (Gast)]

Und nochmal Danke!

[Marcus H. (Firma: www.harerod.de) (lungfish)]

Werner schrieb:
> Diese unzähligen Arten von HALs (mit
> Unterversionen) etc. finde ich sehr frustrierend, das ist unfassbares
> Chaos.

Es lassen sich direkt bei STM Beispielprogramme finden, welche ohne HAL 
auskommen. Wird nicht sonderlich beworben, aber ist aus meiner Sicht die 
einzige Möglichkeit, langfristigen Support für ein Projekt zu 
garantieren.

Was natürlich nicht heißt, dass man sich von HAL-Projekten nicht 
inspirieren lassen darf. ;)

[Chris D. (myfairtux) (Moderator)]

Marcus H. schrieb:
> Werner schrieb:
>> Diese unzähligen Arten von HALs (mit
>> Unterversionen) etc. finde ich sehr frustrierend, das ist unfassbares
>> Chaos.
>
> Es lassen sich direkt bei STM Beispielprogramme finden, welche ohne HAL
> auskommen. Wird nicht sonderlich beworben, aber ist aus meiner Sicht die
> einzige Möglichkeit, langfristigen Support für ein Projekt zu
> garantieren.

Ja, im Referenzhandbuch hat man hinten im Anhang entsprechende kurze 
Code-Schnipsel zu jeder Hardware - ST nennt die "STM32Snippets".

Zusammen mit den sehr guten Kommentaren in den C- und Headerdateien der 
StdLib (hier stm32f0xx_i2c.h/.c) hat man einen guten Leitfaden für die 
Hardwareinitialisierung. Dann vergisst man nichts.

> Was natürlich nicht heißt, dass man sich von HAL-Projekten nicht
> inspirieren lassen darf. ;)

Stimmt :-)

[Framlin (wolfgang_e34)]

Marcus H. schrieb:

> Es lassen sich direkt bei STM Beispielprogramme finden, welche ohne HAL
> auskommen. Wird nicht sonderlich beworben, aber ist aus meiner Sicht die
> einzige Möglichkeit, langfristigen Support für ein Projekt zu
> garantieren.
hast Du da zufällig konkrete „Links“ (evtl sogar für stm32f4)?

Ich möchte nämlich auch direkt die Register ansprechen und hab 
festgestellt, dass fast alle Beispiele „im Internet“ aus einem 
unübersichtlichen Wust von HAL-Code bestehen.

Von daher bin ich über jede Register-Quelle dankbar.

[PaSi (Gast)]

Hallo Wolfgang...

die Register stehen doch alles gut beschrieben im Reference Manual. Da 
solltest du fündig werden. Ansonsten kann man auch nachvollziehen was 
die HAL da entsprechend macht...da werden am Ende auch nur Register 
beschrieben.

Gruß

[Chris D. (myfairtux) (Moderator)]

Wolfgang E. schrieb:
> Marcus H. schrieb:
>
>> Es lassen sich direkt bei STM Beispielprogramme finden, welche ohne HAL
>> auskommen. Wird nicht sonderlich beworben, aber ist aus meiner Sicht die
>> einzige Möglichkeit, langfristigen Support für ein Projekt zu
>> garantieren.
> hast Du da zufällig konkrete „Links“ (evtl sogar für stm32f4)?
>
> Ich möchte nämlich auch direkt die Register ansprechen und hab
> festgestellt, dass fast alle Beispiele „im Internet“ aus einem
> unübersichtlichen Wust von HAL-Code bestehen.
>
> Von daher bin ich über jede Register-Quelle dankbar.

Wie weiter oben schon geschrieben: in den Anhängen zum Referenzhandbuch 
des STM32F0 sind schöne, kurze Beispiele angeführt. Beim 
STM32F4-Referenzhandbuch scheint es die leider nicht zu geben. 
Allerdings sind die Register für eine spezifische Schnittstelle wohl 
ziemlich identisch (ebenso natürlich bei den Timern etc.)

Weitere sehr gute Kommentare finden sich in den Quelldateien zur STLib.

Und natürlich findet man alle Register immer im jeweiligen 
Referenzhandbuch sehr gut beschrieben.

[Framlin (wolfgang_e34)]

@Chris D. @PaSi,

ja, die Register sind gut beschrieben, aber das nützt nur dann etwas, 
wenn man schon genau weiß, welche Register man wofür benutzen muss ;)

Und ja genau, leider finden sich für den STM32F4 im Anhang keine 
Beispiele.
Was das I2C anbelangt, so scheint es da z.B. den Unterschied zu geben, 
dass es für den F0 das I2C->TIMINGR gibt, das man beschreiben muss. Für 
den F4 find ich dazu im Referenzhandbuch allerdings nichts. Entweder ist 
da das Referenzhandbuch falsch, oder es ist da anders gelöst (oder ich 
bin zu blöd das zu finden).

Ich denke, was ich eigentlich suche, sind die Algorithem. Also eine 
Beschreibung, welche Register in welcher Reihenfolge beschrieben und 
ausgelesen werden müssen.
Dann könnte ich im Referenzhandbuch, im Datasheet und in den 
include-files die Details nachlesen.
In den Fällen, in denen ich kurzen BeispielCode habe, komm ich mit dem 
Vorgehen gut klar. (Zumindest viel viel besser, als wenn ich mir Code 
von CubeMX generieren lasse.)

Und natürlich wärs sehr praktisch, wenn man sich für die Algorithmen 
nicht durch Quelltexte hangeln müsste ;)

Aber wenn es so was nicht gibt, bleibt wohl nix anderes übrig.

[m.n. (Gast)]

Wolfgang E. schrieb:
> hast Du da zufällig konkrete „Links“ (evtl sogar für stm32f4)?

Man liest hier immer wieder, das beim F4 die Hardware nicht sauber 
arbeiten soll. Andererseits werden auch Routinen für den F4 
veröffentlicht.
Selber habe ich mit direktem Ansprechen der Register beim F4 viel Zeit 
ohne brauchbaren Erfolg verplempert. Schnell eine alte Soft-IIC-Routine 
auf den F4 umgeschrieben war dagegen die 'Erlösung' ;-)

Wenn man sowieso auf einen IIC-Baustein warten muß und nicht per ISR 
Daten sendet oder empfängt, gibt es kein Zeitproblem. Vorteilhaft 
dagegen ist, daß man (fast) jeden IO-Pin als SCL/SDA wählen kann.

[Harry L. (mysth)]

Wer das Konzept hinter HAL, SPL, CMSIS & Co schon nicht versteht, wird 
es mit Sicherheit selbst nicht besser hinbekommen.

https://de.wikipedia.org/wiki/Dunning-Kruger-Effekt

[Dr. Sommer (Gast)]

Harry L. schrieb:
> Wer das Konzept hinter HAL, SPL, CMSIS & Co schon nicht versteht

Da gibt's nix zu verstehen... Nicht vorhandene Kapselung, keine 
Objekt-Identität, ungeeignete/ineffiziente Datentypen, mysteriöse 
Abläufe, schlechte Dokumentation, ineffiziente Algorithmen, und zu guter 
Letzt noch Bugs. Das geht kaum schlechter :-)

[Chris D. (myfairtux) (Moderator)]

Wolfgang, hier ist bspw. der Kopf aus der StdLib.

Ich finde es schon recht gut aufgeschlüsselt, was man in welcher 
Reihenfolge machen muss.

So eine Beschreibung findet sich im Kopf jeder Moduldatei.

Aber ja, man man muss natürlich die Funktionsaufrufe in die 
entsprechenden Registerbefehle "übersetzen".

Vielleicht hilft Dir das ja.

Edit: ich habe gerade nochmal bei ST geschaut. Diese sog. "STM32Snipets" 
gibt es wohl leider wirklich nur für den F0 und L0:

https://www.st.com/en/embedded-software/stm32snippets.html?querycriteria=productId=LN1898

Sehr schade, denn das ist einfach sehr kompakt und eben rein 
registerorientiert.

/**
  ******************************************************************************
  * @file    stm32f4xx_i2c.c
  * @author  MCD Application Team
  * @version V1.0.2
  * @date    05-March-2012
  * @brief   This file provides firmware functions to manage the following 
  *          functionalities of the Inter-integrated circuit (I2C)
  *           - Initialization and Configuration
  *           - Data transfers
  *           - PEC management
  *           - DMA transfers management
  *           - Interrupts, events and flags management 
  *           
  *  @verbatim
  *    
  *          ===================================================================
  *                                 How to use this driver
  *          ===================================================================
  *          1. Enable peripheral clock using RCC_APB1PeriphClockCmd(RCC_APB1Periph_I2Cx, ENABLE)
  *             function for I2C1, I2C2 or I2C3.
  *
  *          2. Enable SDA, SCL  and SMBA (when used) GPIO clocks using 
  *             RCC_AHBPeriphClockCmd() function. 
  *
  *          3. Peripherals alternate function: 
  *                 - Connect the pin to the desired peripherals' Alternate 
  *                   Function (AF) using GPIO_PinAFConfig() function
  *                 - Configure the desired pin in alternate function by:
  *                   GPIO_InitStruct->GPIO_Mode = GPIO_Mode_AF
  *                 - Select the type, pull-up/pull-down and output speed via 
  *                   GPIO_PuPd, GPIO_OType and GPIO_Speed members
  *                 - Call GPIO_Init() function
  *                 Recommended configuration is Push-Pull, Pull-up, Open-Drain.
  *                 Add an external pull up if necessary (typically 4.7 KOhm).      
  *        
  *          4. Program the Mode, duty cycle , Own address, Ack, Speed and Acknowledged
  *             Address using the I2C_Init() function.
  *
  *          5. Optionally you can enable/configure the following parameters without
  *             re-initialization (i.e there is no need to call again I2C_Init() function):
  *              - Enable the acknowledge feature using I2C_AcknowledgeConfig() function
  *              - Enable the dual addressing mode using I2C_DualAddressCmd() function
  *              - Enable the general call using the I2C_GeneralCallCmd() function
  *              - Enable the clock stretching using I2C_StretchClockCmd() function
  *              - Enable the fast mode duty cycle using the I2C_FastModeDutyCycleConfig()
  *                function.
  *              - Configure the NACK position for Master Receiver mode in case of 
  *                2 bytes reception using the function I2C_NACKPositionConfig().  
  *              - Enable the PEC Calculation using I2C_CalculatePEC() function
  *              - For SMBus Mode: 
  *                   - Enable the Address Resolution Protocol (ARP) using I2C_ARPCmd() function
  *                   - Configure the SMBusAlert pin using I2C_SMBusAlertConfig() function
  *
  *          6. Enable the NVIC and the corresponding interrupt using the function 
  *             I2C_ITConfig() if you need to use interrupt mode. 
  *
  *          7. When using the DMA mode 
  *                   - Configure the DMA using DMA_Init() function
  *                   - Active the needed channel Request using I2C_DMACmd() or
  *                     I2C_DMALastTransferCmd() function.
  *              @note When using DMA mode, I2C interrupts may be used at the same time to
  *                    control the communication flow (Start/Stop/Ack... events and errors).
  * 
  *          8. Enable the I2C using the I2C_Cmd() function.
  * 
  *          9. Enable the DMA using the DMA_Cmd() function when using DMA mode in the 
  *             transfers. 
  *
  *  @endverbatim

[Harry L. (mysth)]

Dr. Sommer schrieb:
> Da gibt's nix zu verstehen... Nicht vorhandene Kapselung, keine
> Objekt-Identität, ungeeignete/ineffiziente Datentypen, mysteriöse
> Abläufe, schlechte Dokumentation, ineffiziente Algorithmen, und zu guter
> Letzt noch Bugs. Das geht kaum schlechter :-)

Ach, du hast es auch nicht verstanden?!

Naja, macht ja nix :-D

Ironie Die Chip-Hersteller sind ja auch alle doof, und kennen ihre 
eigenen Chips nicht, und die Amateuere sind ja sowieso alle viel 
schlauer...

Die Chip-Hersteller machen das sowieso nur, um den Entwicklern das Leben 
schwer zu machen. IronieOff

Solche unqualifizierten, pauschalisierenden Aussagen bringen mich immer 
wieder zum Schmunzeln....

[Dr. Sommer (Gast)]

Harry L. schrieb:
> Ironie Die Chip-Hersteller sind ja auch alle doof,
Richtig. Da arbeiten nur Ingenieure, die keine Ahnung von 
Software-Entwicklung haben und Software nur als Beiwerk sehen. 
Dementsprechend sieht die ganze zugehörige Software dann aus. Starte mal 
STM32CubeMX und schau wie viel RAM das frisst und wie lange es zum 
Starten braucht und überleg wie kompetent der Entwickler wohl gewesen 
sein muss. Und nein, Java ist da nicht dran schuld - auch wenn die 
ST-Mitarbeiter das in ihren Webcasts als "Entschuldigung" angeben...


Harry L. schrieb:
> Ach, du hast es auch nicht verstanden?!
Kann natürlich sein, dass es einer ganz besonders obskuren Logik 
folgt... Die ist dann aber für normale Nutzer auch nicht vorteilhaft :-)

[Harry L. (mysth)]

Dr. Sommer schrieb:
> Starte mal
> STM32CubeMX und schau wie viel RAM das frisst und wie lange es zum
> Starten braucht

Das ist mir sowas von egal...

Auf einem (meinem) halbwegs aktuellen Rechner läuft das ganz wunderbar 
performant, und das Laufzeitverhalten von CubeMX hat nicht das geringste 
mit der Performance des Code auf dem µC zu tun.

*Dummes Argument!*

Dr. Sommer schrieb:
> ganz besonders obskuren Logik
> folgt... Die ist dann aber für normale Nutzer auch nicht vorteilhaft

Was ist denn ein "normaler Nutzer"?
Meinst du die "Arduino-Helden" und "Schlaumeier" hier, die zwar keine 
Ahnung haben, aber sowieso und immer glauben, alles besser zu können?

Die sind nicht repräsentativ!

[(prx) A. K. (prx)]

Harry L. schrieb:
> Ironie Die Chip-Hersteller sind ja auch alle doof, und kennen ihre
> eigenen Chips nicht,

Einen Eindruck, denn ich vor etlichen Jahren beim Blick auf Teile der 
Lib ganz ohne Ironie so stehen lassen möchte. Ich würde auch nicht 
darauf wetten, dass es die Cracks des Hauses sind, die mit der 
Entstehung solcher Libs befasst sind.

[Harry L. (mysth)]

A. K. schrieb:
> vor etlichen Jahren beim Blick in die
> Baudratenberechnung der Lib ganz ohne Ironie so stehen lassen möchte.

Ja, vor Jahren, aber die Hersteller haben inzw. auch verstanden, wie 
wichtig solche Frameworks für die Anwender der Chips sind, und die 
werden kontinuierlich weiter entwickelt.

A. K. schrieb:
> Ich würde auch nicht darauf wetten, dass es die Cracks des Hauses sind,
> die mit der Entstehung solcher Libs befasst sind.

Ich hab schon den Eindruck, daß da inzw. (vielleicht war das früher mal 
anders) durchaus fähige Ingenieure mit beschäftigt sind.

[Dr. Sommer (Gast)]

Harry L. schrieb:
> *Dummes Argument!*

Achso, Inkompetenz ist nur dann eine solche wenn das Ergebnis zum Tragen 
kommt? STM32CubeMX ist nur ein leicht nachvollziehbares Beispiel. Ein 
Blick in die Sourcen von HAL dauert länger, führt aber zur gleichen 
Erkenntnis.

Übungsaufgaben:
1.) Schreibe eine Funktion, welcher ein GPIO zur Nutzung mit Alternate 
Function mit einer bestimmtem Peripherie übergeben wird. Gutes API:

myFunction (GPIOA_13);

Schlechtes API:

myFunction (GPIOA, GPIO_Pin_13, RCC_AHBENR_GPIOAEN, &RCC->AHBENR, GPIO_AF_5);

Zu welcher Kategorie gehört die HAL?

2.) Betrachte den Quelltext der Funktion HAL_GPIO_TogglePin, sowie die 
Dokumentation des Registers GPIOx_BSRR. Überlege, was passiert, wenn 
während der Funktion ein Interrupt auftritt. Was fällt auf?

3.) Das Linkerscript zum STM32F4 in den Beispielprogrammen 
intialisiert(e) den Stack auf die letzte Adresse im RAM, als wäre der 
Prozessor eine Post-Dekrement-Architektur; tatsächlich ist es aber 
Pre-Dekrement. Warum macht man das so? Weil es ja auch so 
"funktioniert"?

Harry L. schrieb:
> Was ist denn ein "normaler Nutzer"?
Jemand, der saubere Programmstrukturen und OOP gewöhnt ist.

[Harry L. (mysth)]

Dr. Sommer schrieb:
> Achso, Inkompetenz ist nur dann eine solche wenn das Ergebnis zum Tragen
> kommt? STM32CubeMX ist nur ein leicht nachvollziehbares Beispiel.

Das interessiert doch nur Leute, die seit >10J mit ihrer alten XP-Möhre 
arbeiten...
Auf modernen Rechnern läuft das wunderbar.
CubeMX braucht bei mir nicht länger zum Starten als LibreOffice-Calc.

Dr. Sommer schrieb:
> myFunction (GPIOA_13);Schlechtes API:myFunction (GPIOA, GPIO_Pin_13,
> RCC_AHBENR_GPIOAEN, &RCC->AHBENR, GPIO_AF_5);Zu welcher Kategorie gehört
> die HAL?

Ich sehe da keine HAL.Funktionen

Dr. Sommer schrieb:
> 2.) Betrachte den Quelltext der Funktion HAL_GPIO_TogglePin, sowie die
> Dokumentation des Registers GPIOx_BSRR. Überlege, was passiert, wenn
> während der Funktion ein Interrupt auftritt. Was fällt auf?

Gar nichts fällt mir da auf....

void HAL_GPIO_TogglePin(GPIO_TypeDef* GPIOx, uint16_t GPIO_Pin)
{
  /* Check the parameters */
  assert_param(IS_GPIO_PIN(GPIO_Pin));

  GPIOx->ODR ^= GPIO_Pin;
}

Was stört dich daran?

Dr. Sommer schrieb:
> 3.) Das Linkerscript zum STM32F4 in den Beispielprogrammen
> intialisiert(e) den Stack auf die letzte Adresse im RAM, als wäre der
> Prozessor eine Post-Dekrement-Architektur; tatsächlich ist es aber
> Pre-Dekrement. Warum macht man das so?

Auf welche Adresse soll er den Stack denn sonst initialisieren?
Wenn man in Sonderfällen den Stack tatsächlich wo anders haben will, 
kann man da ja jederzeit manuell eingreifen.
Einmal geändert überleben die Änderungen auch folgende Generator-Läufe

Dr. Sommer schrieb:
> Harry L. schrieb:
>> Was ist denn ein "normaler Nutzer"?
> Jemand, der saubere Programmstrukturen und OOP gewöhnt ist.

Ach, jetzt geht das Theater wieder los....
Jaja...mit OOP ist ja alles so viel besser....
Soll ja gerüchteweise auch Leute geben, die auch ganz ohne OOP-Sprachen 
sauber programmieren können.

[(prx) A. K. (prx)]

Harry L. schrieb:
>   GPIOx->ODR ^= GPIO_Pin;
> Was stört dich daran?

Erzeugter Code:
  reg = ODR;
  reg = reg ^ bit;
  ODR = reg;
Und nun überleg was passiert, wenn zwischendrin ein Interrupt reinhaut 
in dem ein anderes Bit des Ports verändert wird.

Wenn man das mit dem BSRR macht, ist das kein Problem. Mit ODR schon. 
Grundwissen Mikrocontroller.

[Dr. Sommer (Gast)]

Harry L. schrieb:
> Das interessiert doch nur Leute, die seit >10J mit ihrer alten XP-Möhre
> arbeiten...

Es zeigt trotzdem dass die Programmierung schlecht ist.

Harry L. schrieb:
> Ich sehe da keine HAL.Funktionen
Ja, weil es keine gibt die das vernünftig kapselt - das wäre in einer 
HAL sinnvoll gewesen!

Harry L. schrieb:
> Was stört dich daran?
Das "^=" wird zu einem read-modify-write-Zyklus kompiliert. Wenn während 
des "modify" ein Interrupt kommt, welcher einen anderen Pin des 
selben Ports ändert, überschreibt das "write" diese Änderung wieder, 
und man hat einen inkonsistenten Zustand. Mit dem "BSRR" Register ließe 
sich das wunderbar vermeiden - aber die ST-Leute kennen ihre eigenen 
Chips halt nicht so gut.

Harry L. schrieb:
> Auf welche Adresse soll er den Stack denn sonst initialisieren?
Auf die 1. nach dem RAM.

Harry L. schrieb:
> Wenn man in Sonderfällen den Stack tatsächlich wo anders haben will,
> kann man da ja jederzeit manuell eingreifen.
Man will das nie so haben wie im Beispiel, denn das ist langsamer, 
verschwendet 1 Byte RAM, und führt je nach Einstellung sogar zum Absturz 
des Controllers. Es gibt absolut keinen Grund, das so zu machen - außer 
man kennt den eigenen Controller nicht.

Harry L. schrieb:
> Jaja...mit OOP ist ja alles so viel besser....
Ja, deswegen ist das auch seit Jahrzehnten das etablierteste Paradigma. 
Es gibt mehr Sprachen die es direkt unterstützten, also solche die es 
nicht tun. Warum also hier nicht? 1 Pin = 1 Objekt, ein I²C-Controller = 
1 Objekt würde doch perfekt passen. Aber nein, 1 Pin = 1 Port + 1 
Pinnummer + 1 RCC-Register + 1 RCC-Takt ...

[Framlin (wolfgang_e34)]

@Chris D. Danke!

[Framlin (wolfgang_e34)]

Ohhhjeeee, ich hab das C-Wort geschrieben, das tut mir leid das wollte 
ich nicht, ich hätte wissen müssen, was das auslöst ;-)

Aus meiner Sicht ist es ganz einfach. Manche Menschen kommen mit dem 
einen Paradigma gut zurecht, andere mit einem anderen.

Ich persönlich habe festgestellt, dass ich mit CubeMX nicht klar 
komme. Das verwirrt mich einfach nur.
Das kommt evtl. daher, dass ich mit OOP "sozialisiert" wurde. Daher 
verstehe ich entsprechenden Code einfach besser.

In meinem Quelltext steht

LED led(0, 5); /*PA5*/
led = ON;
//... do something meaningfull
led = OFF;

Servo servo(0, 6); /*PA6*/
servo.start();
servo.degree(30);

Da ich von MicroController-Programmierung wenig bis gar keine Ahnung 
habe, ist es für mich auch entscheidend, dass ich so viel wie möglich 
selber codiere. Nur so hab ich ne Chance herauszufinden, wo das Problem 
liegt, wenn die LED nicht blinkt wie erwartet.

Wenn der Servo sich nicht bewegt, hab ich in nem generierten HAL-code 
keine Chance herauszufinden, warum das so ist.
Wenn ich mich dagegen durch von mir selber gesetzte Register hangle, hab 
ich erstens ne ziemlich genaue Vorstellung davon, was sich überhaupt tut 
und dadurch fällt es mir zweitens deutlich leichter mir zu überlegen, wo 
ich was falsch gemacht habe.

Wenn sich jemand gut mit uC auskennt und mit OOP nichts anfangen kann, 
sind CubeMX und HAL bestimmt sehr praktisch und sparen Zeit und Geld.

Für mich gilt das nicht.

[Carl D. (jcw2)]

Dr. Sommer schrieb:
> Harry L. schrieb:
>> Was stört dich daran?
> Das "^=" wird zu einem read-modify-write-Zyklus kompiliert. Wenn während
> des "modify" ein Interrupt kommt, welcher einen anderen Pin des
> selben Ports ändert, überschreibt das "write" diese Änderung wieder,
> und man hat einen inkonsistenten Zustand. Mit dem "BSRR" Register ließe
> sich das wunderbar vermeiden - aber die ST-Leute kennen ihre eigenen
> Chips halt nicht so gut.

Ok, "^=" ist ohne Int-Sperre nur gut, wenn man gern sporadische Fehler 
sucht.
Aber auch ein "Toggle" via BSSR ist nicht wirklich atomar. Nur solange 
die beteiligten "Threads" wirklich unterschiedliche Bits verwenden, geht 
es immer gut.
Ich gebe zu, das ist konstruiert, BSSR ist eben für Toggle nicht immer 
100%tig sicher. Andere Chips haben dafur explizit ein "Toggle"-Register, 
z.B. XMega (wenn auch von mir nie benutzt).

Aber ansonsten: FullAck, wer nicht ahnt, was die Maschine mit einem 
Hochsprachenstatement macht, der kann ordentlich reinfallen.

[(prx) A. K. (prx)]

Carl D. schrieb:
> Aber auch ein "Toggle" via BSSR ist nicht wirklich atomar. Nur solange
> die beteiligten "Threads" wirklich unterschiedliche Bits verwenden, geht
> es immer gut.

Natürlich. Aber der gleiche Portpin hat nur selten in mehreren 
getrennten Software-Modulen eine Funktion.

Wenn man also davon ausgeht, dass ein Portpin nur in einem Modul 
verwendet wird, dann liegt der betroffene Code eng beieinander und es 
liegt in der Verantwortung dieses Moduls, es richtig zu machen.

Getrennte Module hingegen entwickeln sich getrennt voneinander, ggf von 
getrennten Personen zu sehr unterschiedliche Zeiten. Wenn man da solche 
Probleme einbaut, dann baut man eine Falle ein, die irgendwann 
zuschnappt.

> Ich gebe zu, das ist konstruiert, BSSR ist eben für Toggle nicht immer
> 100%tig sicher. Andere Chips haben dafur explizit ein "Toggle"-Register,
> z.B. XMega (wenn auch von mir nie benutzt).

Es geht nicht allein um das eher seltene Toggle an sich. Ein anderes 
Beispiel sind die 4 Datenbits von Text-LCDs. Oder auch schon die 
Steuerung eines einzelnen Pins.

Wie setzt man einen Subset von Pins auf einen Wert, gleichzeitig oder 
nacheinander, ohne eine solche Falle einzubauen? Dafür hat jeder 
Hersteller von Mikrocontrollern eine eigene Methode entwickelt, die sich 
auch für Einzelbits und Bitgruppen völlig unterscheiden kann.

Eine allgemeine Lösung für Einzelbits bietet ARMs Bitbanding, soweit 
implementiert. Andere Architekturen können Bits in einem für Interrupts 
unaufbrechbaren r/m/w Befehl setzen (generell CISCs, AVR).

STM verwendet für Einzelbits und Bitgruppen das BSRR (was ich für sehr 
clever halte). Andere ARMe haben getrennte Set- und Reset-Register, was 
es in 2 Operationen auftrennt, eine für 1en und eine für 0en. Bei nicht 
zu alten AVRs kann man ins IN Register schreiben, um das Problem zu 
lösen.

Manche Typen, vor allem alte, bieten dafür überhaupt keine Lösung 
jenseits des Abschaltens von Interrupts. Bei 8-Bit breiten Ports 
entsteht der Konflikt auch weniger häufig als bei 32-Bit Ports und bei 
einfachen Interrupt-Systemen tut das auch weniger weh als bei komplexen.

Deshalb: Das Problem gehört zum Grundwissen von Mikrocontrollern. Die 
Lösung indes nicht, die ist überall anders.

[Carl D. (jcw2)]

A. K. schrieb:
> <viel>

Ruhig Blut!
Kenn ich alles, aber es ging um den ganz konkreten Fall "Toggle" und da 
reicht BSSR nicht aus, da braucht man auch IDR.

[Harry L. (mysth)]

Dr. Sommer schrieb:
> Es zeigt trotzdem dass die Programmierung schlecht ist.

Nein, das zeigt nur, daß dein Rechner scheinbar zu alt damit offenbar 
überfordert ist.
Da du auch keinen Einblick in den Source hast, sind alles andere nur 
haltlose Unterstellungen.

Dr. Sommer schrieb:
> Das "^=" wird zu einem read-modify-write-Zyklus kompiliert. Wenn während
> des "modify" ein Interrupt kommt, welcher einen anderen Pin des
> selben Ports ändert, überschreibt das "write" diese Änderung wieder,
> und man hat einen inkonsistenten Zustand. Mit dem "BSRR" Register ließe
> sich das wunderbar vermeiden - aber die ST-Leute kennen ihre eigenen
> Chips halt nicht so gut.

Vollkommen konstruierte Situation, aber das haben Andere oben ja bereits 
ebenfalls erkannt.
Würde man alle diese Sonderfälle in einer so simplen Funktion wie Toggle 
berücksichtigen, käme genau das dabei heraus, was du weiter oben ja 
unterstellst:

"Augfgeblasener und umperformanter Code"

HAL soll den Entwickler von Routine-Aufgaben entlasten, und nicht vom 
eigenständigen Denken.

Dr. Sommer schrieb:
> Harry L. schrieb:
>> Auf welche Adresse soll er den Stack denn sonst initialisieren?
> Auf die 1. nach dem RAM.
>
> Harry L. schrieb:
>> Wenn man in Sonderfällen den Stack tatsächlich wo anders haben will,
>> kann man da ja jederzeit manuell eingreifen.
> Man will das nie so haben wie im Beispiel, denn das ist langsamer,
> verschwendet 1 Byte RAM, und führt je nach Einstellung sogar zum Absturz
> des Controllers. Es gibt absolut keinen Grund, das so zu machen - außer
> man kennt den eigenen Controller nicht.

Die Aussage ist schlicht falsch, wie ein Blick in ein von CubeMX 
generiertes Linker-File zeigt:

/* Entry Point */
ENTRY(Reset_Handler)

/* Highest address of the user mode stack */
_estack = 0x20020000;    /* end of RAM */
/* Generate a link error if heap and stack don't fit into RAM */
_Min_Heap_Size = 0x200;      /* required amount of heap  */
_Min_Stack_Size = 0x400; /* required amount of stack */

Dr. Sommer schrieb:
>> Jaja...mit OOP ist ja alles so viel besser....
> Ja, deswegen ist das auch seit Jahrzehnten das etablierteste Paradigma.
> Es gibt mehr Sprachen die es direkt unterstützten, also solche die es
> nicht tun. Warum also hier nicht? 1 Pin = 1 Objekt, ein I²C-Controller =
> 1 Objekt würde doch perfekt passen. Aber nein, 1 Pin = 1 Port + 1
> Pinnummer + 1 RCC-Register + 1 RCC-Takt ...

Das solltest du dringend mal den Linux-Kernel-Entwicklern erzählen!
Die wissen das ja scheinbar alle noch nicht.

Deine ganze Argumentations-Kette ist äußerst dünn, und alles, was du 
damit beweist, ist, daß DU HAL nicht willst.

Wer nicht mit der Zeit geht, der geht eben mit der Zeit....

[(prx) A. K. (prx)]

Carl D. schrieb:

> und da reicht BSSR nicht aus, da braucht man auch IDR.

Also wo du dich schon drüber mokierst, dass ich für dich zu ausführlich 
antwortete, will ich den Ball mal zurückspielen. Denn ich war davor 
offenbar nicht ausführlich genug. ;-)

Wenn ich schrieb, dass es mit BSRR geht, dann wollte ich damit 
ausdrücken, dass das BSRR der entscheidende Teil dabei ist. Das Wissen 
darüber, dass man dafür auch noch das ODR(!) braucht und dass man für 
den Betrieb des µCs Strom und Takt braucht, das nahm ich als vorhanden 
an. ;-)

Aber wo wir schon dabei sind, echte oder scheinbare 
Selbstverständlichkeiten zu wiederholen: Das IDR ist dafür meist das 
falsche Register. Wenn der Port nämlich als open drain konfiguriert ist. 
Also besser ODR verwenden. Da steht der bisherige Sollzustand drin, im 
IDR der Istzustand.

[Dr. Sommer (Gast)]

Harry L. schrieb:
> Da du auch keinen Einblick in den Source hast, sind alles andere nur
> haltlose Unterstellungen.

Selbst die ST-Mitarbeiter finden CubeMX zu langsam. Und das geht 
definitiv besser. Das kann man auch sagen ohne den Code zu sehen.

Harry L. schrieb:
> Vollkommen konstruierte Situation, aber das haben Andere oben ja bereits
> ebenfalls erkannt.
Ich bin da mal böse drüber gestolpert. Es könnte so einfach sein - 2 
bitweise Operationen mehr, und alles wäre gut. Das wäre keineswegs 
aufgeblasen.

Harry L. schrieb:
> Die Aussage ist schlicht falsch, wie ein Blick in ein von CubeMX
> generiertes Linker-File zeigt:
Davon hab ich auch nicht geredet, sondern vom STM32F4-Beispielcode aus 
dem CubeF4-Download. Kann sein dass das mittlerweile repariert ist; noch 
vor wenigen Jahren war es falsch. Da gibt's hier auch einige Threads zu.

Harry L. schrieb:
> Das solltest du dringend mal den Linux-Kernel-Entwicklern erzählen!
> Die wissen das ja scheinbar alle noch nicht.
Die programmieren tatsächlich weitgehend OOP.

Harry L. schrieb:
> Wer nicht mit der Zeit geht, der geht eben mit der Zeit....
Ganz genau - statt eines HAL in der veralteten Sprache "C" im veralteten 
prozeduralen Paradigma könnte man so etwas mit OOP und 
template-Metaprogrammierung super in C++ machen. Aber dann müssten die 
ganzen Leute ja, oh Graus, was neues lernen.

[Harry L. (mysth)]

Dr. Sommer schrieb:
> Selbst die ST-Mitarbeiter finden CubeMX zu langsam. Und das geht
> definitiv besser. Das kann man auch sagen ohne den Code zu sehen.

Glauben oder Wissen?
Belege?

Ach so, du kennst den Source ja auch nicht - also lassen wir das.

Dr. Sommer schrieb:
> noch
> vor wenigen Jahren

In der IT-Welt liegen dazwischen Welten...

Dr. Sommer schrieb:
> Harry L. schrieb:
>> Das solltest du dringend mal den Linux-Kernel-Entwicklern erzählen!
>> Die wissen das ja scheinbar alle noch nicht.
> Die programmieren tatsächlich weitgehend OOP.

Schau dir den Linux-Kernel an!
Da gibts fast nur C aber kein C++.

Und jetzt bin ich hier raus...

Dieser Dogmatismus ist mir einfach zu langweilig....

[(prx) A. K. (prx)]

Dr. Sommer schrieb:
>> Vollkommen konstruierte Situation, aber das haben Andere oben ja bereits
>> ebenfalls erkannt.
> Ich bin da mal böse drüber gestolpert.

Ich betrachte das ebenfalls nicht als konstruiert. Und je mehr Bits ein 
GPIO Port hat, umso wahrscheinlicher wird er in diversen getrennten 
Modulen genutzt, und desto wahrscheinlicher ist eine solche race 
condition.

Was jemand in einer Anwendung macht ist sein Bier. Aber in eine separate 
Lib für eine bestimmte µC-Familie gehört eine möglichst sichere 
Implementierung, wenn das ohne Aufwand und ohne andere Nebenwirkungen 
möglich ist.

[Dr. Sommer (Gast)]

Harry L. schrieb:
> Glauben oder Wissen?
> Belege?

Simple Logik. Beim Starten werden nur wenige MB Daten gebraucht - 
nämlich die Liste aller IC's und ihrer Features. Dennoch braucht es 
lange zum Starten und frisst GBytes an RAM. Muss das sein?

Harry L. schrieb:
> Schau dir den Linux-Kernel an!
> Da gibts fast nur C aber kein C++.
Ok. Worauf soll ich achten? Einfach nur Millionen LoC anstarren und 
sagen "Aha, die Leute bei ST sind doch kompetent"?

Harry L. schrieb:
> In der IT-Welt liegen dazwischen Welten...
Ok, ich lade es "eben" herunter (sind ja nur 400MB) und schaue nach.

Harry L. schrieb:
> Dieser Dogmatismus ist mir einfach zu langweilig....
Wieso ist es Dogmatismus, sich etwas anzuschauen und für schlecht zu 
befinden?

[Harry L. (mysth)]

Dr. Sommer schrieb:
> Wieso ist es Dogmatismus, sich etwas anzuschauen und für schlecht zu
> befinden?

Wenn man nur lange genug mit dem Kopf schüttelt, findet man in jeder 
Suppe ein Haar....

[Gerhard O. (gerhard_)]

Ich habe nicht den ganzen Thread gelesen und habe vielleicht was 
übersehen.
Vor vielen Jahren (2010+) hatte ich mit sehr guten Erfolg die 
Information in AN2824 auf einem F103 und F407 angewendet.

https://www.st.com/resource/en/application_note/cd00209826.pdf

Den Source Code gibt es auch irgendwo. Ich verwendete nur den Interrupt 
Betrieb, also nicht DMA oder Polling und die Resultate waren sehr gut 
damit.

Ich versuchte vorher mit meinem eigenen Code direkt auf Register 
zuzugreifen, hatte aber Probleme mit ACK Polling wenn ich z.B. EEPROMs 
beschrieb. Ich bin dann davon abgegangen, zugunsten der AN2824 
Vorschläge weil ich davon ausging, dass die I2C Hardware State Machine 
Register so gelesen und beschrieben werden müssen wie es das HW design 
es verlangt. Direkter Register Übergriff ist da nicht unbedingt 
anzuraten weil die Status Bits vom Ablauf der State Machine gesteuert 
sind und für einwandfreien Betrieb interne Bedingungen der HW streng 
erfüllt werden müssen. Das Datenblatt war da nicht gerade sehr hilfreich 
weil das Ganze damals nur sehr kryptisch und kurz beschrieben wurde. 
Jedenfalls funktionierten die AN2824 Konzepte fuer mich einwandfrei. Ich 
verwendete damals übrigens die STD-Peripheral Library und nicht die 
neuere HAL/CUBE unter Atollic.

[(prx) A. K. (prx)]

Harry L. schrieb:
> Wenn man nur lange genug mit dem Kopf schüttelt, findet man in jeder
> Suppe ein Haar....

Wenn jemand Mozart liebt und Saxon hasst, dann darf man ihn zwar fragen, 
was er in Wacken will. Aber ihn für Mozart zu kritisieren geht zu weit. 
Da gibts kein besser oder schlechter, das ist Geschmack.

Software ist anders, Technik generell. Da gibt es oft ein besser und 
schlechter. Wenn man Quellcode veröffentlich, dann wirft man sich damit 
unweigerlich den Kritikern zum Frass vor. Das muss man abkönnen. 
Sachliche Kritik muss erlaubt sein, vielleicht führts ja am Ende sogar 
zu einer besseren Lösung.

[Dr. Sommer (Gast)]

Harry L. schrieb:
> In der IT-Welt liegen dazwischen Welten...

Ich hab nachgesehen, es ist immer noch falsch, interessanterweise aber 
nur in manchen Dateien! Im Paket STM32CubeF4 die Datei

en.stm32cubef4\STM32Cube_FW_F4_V1.21.0\Projects\STM32446E_EVAL\Examples\ 
TIM\TIM_7PWMOutput\SW4STM32\STM32446E_EVAL\STM32F446ZETx_FLASH.ld

enthält:

_estack = 0x2001FFFF;    /* end of RAM */

Wenn man das in einem Programm nutzt, wo z.B. eine "double" oder eine 
"long long" Variable auf dem Stack abgelegt wird (z.B. bei einer 
Parameter-Übergabe), und der Compiler die LDRD oder STRD Instruktion für 
den Zugriff generiert (wahrscheinlich), stürzt der Controller ab. Schon 
recht mies.

[Harry L. (mysth)]

Und daß es in einem der uralt-Beispiele falsch ist beweist jetzt was 
genau?
Wenn man sich das Linker-Script von CubeMX generieren läst, ist es 
korrekt, und das ist alles, was zählt.

[Dr. Sommer (Gast)]

Harry L. schrieb:
> Und daß es in einem der uralt-Beispiele falsch ist beweist jetzt was
> genau?

Das Beispiel ist aktuell. Es beweist, dass die Leute bei ST die eigene 
Hardware nicht kennen.

Harry L. schrieb:
> Wenn man sich das Linker-Script von CubeMX generieren läst, ist es
> korrekt, und das ist alles, was zählt.
Viele Leute fangen mit Beispielen an. Dafür sind die schließlich da. 
Insbesondere bei komplexeren Dingen wie USB möchte man nicht immer alles 
selbst einstellen.

[Harry L. (mysth)]

Dr. Sommer schrieb:
> Das Beispiel ist aktuell. Es beweist, dass die Leute bei ST die eigene
> Hardware nicht kennen.

Nein, das beweist nur, daß die Beispiele seit Ver. 1.0 nicht mehr 
gepflegt wurden.
Leider ist keines der mitgelieferten Beispiele mit CubeMX kompatibel.

[Carl D. (jcw2)]

A. K. schrieb:
> Selbstverständlichkeiten zu wiederholen: Das IDR ist dafür meist das
> falsche Register. Wenn der Port nämlich als open drain konfiguriert ist.
> Also besser ODR verwenden. Da steht der bisherige Sollzustand drin, im
> IDR der Istzustand.

erwischt beim vertippen ;-)

Sonst: Harry verstehst nicht, ich schon!

[Marcus H. (Firma: www.harerod.de) (lungfish)]

m.n. schrieb:
> Wolfgang E. schrieb:
>> hast Du da zufällig konkrete „Links“ (evtl sogar für stm32f4)?
>
> Man liest hier immer wieder, das beim F4 die Hardware nicht sauber
> arbeiten soll. Andererseits werden auch Routinen für den F4
> veröffentlicht.
> Selber habe ich mit direktem Ansprechen der Register beim F4 viel Zeit
> ohne brauchbaren Erfolg verplempert. Schnell eine alte Soft-IIC-Routine
> auf den F4 umgeschrieben war dagegen die 'Erlösung' ;-)
>
> Wenn man sowieso auf einen IIC-Baustein warten muß und nicht per ISR
> Daten sendet oder empfängt, gibt es kein Zeitproblem. Vorteilhaft
> dagegen ist, daß man (fast) jeden IO-Pin als SCL/SDA wählen kann.

Willkommen im Club. Meine aktuelle Politik zu I2C ist folgende:
- wenn das I2C-Timing hinreichend zeitunkritisch ist, verwende ich 
Bitbongo-Standardbibliotheken, quer über alle von mir betreuten 
Controller.
- erfahrungsgemäß ist das industrie- (oder automotive, aero-/defense-) 
taugliche Handling von Hardware-I2C eine trickreiche Sache. Ich habe 
schon mehr als eine I2C-Engine gesehen, die man so ins Nirvana schießen 
kann, dass ein Power-Cycle notwendig wird, um das System wieder 
aufzustarten. Wenn ein Kunde das braucht und will, dann gibt es das 
projektspezifisch gegen Aufwandsabrechnung.
Das heißt nicht, dass die Herstellerbeispiele auf dem Labortisch nicht 
laufen, aber unter Feldbedingungen wird es Szenarien geben, in denen 
sich das Teil aufhängt. Die bereits mehrfach erwähnte Doku ist ein 
Anfangspunkt, das Austesten/Debuggen wird gern mal zum Fass ohne Boden.

War diesen Spaß selber erleben möchte: RT*M, RT*Erratasheet, read the 
Internet, Nachbauen, in der konkreten Anwendung testen, testen, testen.
Oder eben Bitbongo, das tut in kurzer Zeit auf jedem System. Und 
Bitbongo hilft auch beim Freikratzen von abgestürzten Slave-Engines, 
denn dieses Thema gibt es ja auch noch.

[Bernd K. (prof7bit)]

Harry L. schrieb:
>> Die programmieren tatsächlich weitgehend OOP.
>
> Schau dir den Linux-Kernel an!
> Da gibts fast nur C aber kein C++.

Was hat denn bitteschön das eine mit dem anderen zu tun?

[Bernd K. (prof7bit)]

Marcus H. schrieb:
> Bitbongo

Was soll das sein, Google findet nichts?

[Christopher J. (christopher_j23)]

Dr. Sommer schrieb:
> _estack = 0x2001FFFF;    /* end of RAM */

Diese Praxis habe ich übrigens als erstes bei Atollic gesehen (als 
TrueStudio noch richtig Geld kostete), wobei dann die Jungs von AC6 das 
einfach blind in ihre SW4STM32 übernommen haben. ST hat dann wiederum 
blind diesen Quatsch in deren Beispielcode übernommen.


Bernd K. schrieb:
> Marcus H. schrieb:
>> Bitbongo
>
> Was soll das sein, Google findet nichts?

Ich vermute mal es handelt sich hier um die afrikanische Version von 
Bitbanging ;) Vorzugsweise wird das Montags gemacht. Montag ist 
Bongo-Tag.

[m.n. (Gast)]

Marcus H. schrieb:
> Willkommen im Club.

Du brauchst noch meine Kto.-Nr? ;-)

Bernd K. schrieb:
> Marcus H. schrieb:
>> Bitbongo
>
> Was soll das sein, Google findet nichts?

Deutsch: Pinwackeln.

[Marcus H. (Firma: www.harerod.de) (lungfish)]

m.n. schrieb:
> Marcus H. schrieb:
>> Willkommen im Club.
> Du brauchst noch meine Kto.-Nr? ;-)
Wenn Du eine Leistung anbietest, die ich brauche und von der Steuer 
absetzen kann - warum nicht? :P

>
> Bernd K. schrieb:
>> Marcus H. schrieb:
>>> Bitbongo
>>
>> Was soll das sein, Google findet nichts?
>
> Deutsch: Pinwackeln.
Ich bitte um Entschuldigung. Normalerweise versuche ich die Anzahl der 
Fremdwörter wenn möglich zu beschränken, aber es war ein langer Tag 
gestern und ich habe ungefähr gleichviele Gespräche/Elektronische 
Nachrichten auf Japanisch, Englisch und Deutsch gehabt.
Zum Glück haben die Mitleser hier schon weitergeholfen.
Ich meinte tatsächlich: "unter Zuhilfenahme von 
Zentralverarbeitungseinheitsbefehlen die elektrische Spannung der 
Anschlussbeine direkt beeinflussen"

Ansonsten hätte ich gerade bei Bernd nicht mit dem Zuschnappen der 
Generationenfalle gerechnet.
Was das ist? Naja, die heutige Jugend spricht eine andere Sprache, bzw. 
hat die Wörter neu belegt.
Letztes Wintersemester hat hier an der Uni in einem vollen Hörsaal kein 
einziger Erstsemester gewusst, was ein "Fernsprecher" ist. Der 
nächstbeste Treffer war "wenn jemand ein Haus mit Garten hat und einen 
Lautsprecher mit langem Draht am Gartentörchen anbringt". Hat mich 
schwer erschüttert.

[Bernd K. (prof7bit)]

Marcus H. schrieb:
>>>> Bitbongo
>>>
>>> Was soll das sein, Google findet nichts?
>>
>> Deutsch: Pinwackeln.
> Ich bitte um Entschuldigung. Normalerweise versuche ich die Anzahl der
> Fremdwörter wenn möglich zu beschränken,

Fremdwort? Das war kein Fremdwort, das war ein Phantasiewort das Du Dir 
ausgedacht hast, und dann noch irreführenderweise im Zusammenhang mit 
ner vermeintlich existierenden gleichnamigen Library erwähnt, so daß man 
anfängt nach der Webseite des Bitbongo-Projekts zu suchen weil die Jungs 
von der Bitbongo Truppe angeblich unter anderem nen tollen universellen 
I2C-Treiber released haben sollen.

Wen Du Bitbanging (das altbekannte Verfahren) meinst dann schreib das 
doch auch und denk Dir keine neuen Phantasiewörter aus mit denen man 
Leute in die Irre führen kann. Noch dazu wenn Du es so verwendest daß es 
suggeriert es gäbe ein gleichnamiges Projekt oder Produkt.

> Generationenfalle gerechnet.
> Was das ist? Naja, die heutige Jugend spricht eine andere Sprache

Das Wort Bitbongo kommt in Deinem angeblichen neuzeitlichen Jugend-Slang 
jedenfalls nicht vor. Andernfalls hätte Google es schon längst im 
Suchindex erfasst. Bitbanging hingegen ist ein etablierter Begriff.

Das Geschwurbel von "Zentralverarbeitungseinheitsbefehlen" hättest Du 
Dir in Deiner halbherzigen Entschuldigung übrigens ebenfalls schenken 
können.

[Stefan F. (Gast)]

Wenn man etwas Bangt wird daraus ein Bongo, ist doch klar.
Zumindest für alle, die dieses Lied kennen: 
https://www.youtube.com/watch?v=v9MFfC4_lYM