NRF24L01 SPI Problem bringt mich noch zum Wahnsinn!

[Christian J. (Gast)]

Hallo,

das Forum ist echt die letzte Hoffnung weil ich nach 4 Tagen Sucherei 
keine Antwort mehr weiss. Alles scheint richtig zu sein aber diese 
verfl. Module hängen sich nach einer Weile einfach auf und antworten 
nicht mehr :-(((

Setup:
Empfämnger: STM32F4 CPU (Empfänger) im Interrupt
Sender: Arduino Pro Mini mit MIRF Library

Senderseitig ist alles ok, die LIb habe ich mir angeschaut, so sieht es 
auch bei mir aus. Es kommen ja auch laufen die richtigen Messwerte der 
Sensoren an.

Aber der Empfänger .... inzwischen alles runtergestripped, nur noch die 
Routinen, die ich brauche.

IM Bild eine typische SPI Kommunikation mit 1.3 Mhz , einfach mal eine 
Statusabfrage READ+Register 07 100 Mal rausgehauen, es müsste immer der 
gleiche Wert kommen. Nämlich 0x40.

Ab dem 32.ten Byte bricht es ab, dann antwortet das Modul nicht mehr. 
Niemals mehr, außer ich starte das System per Warmstart neu und 
initialisieren das Modul erneut.

32 Byte, das ist genau die maximale Payload Size, wobei 3 x 32 Byte in 
den Fifo passen. Zumindest auffällig.

Woran könnte das noch liegen? Mir fällt absolut nichts mehr ein!

Gruss,
Christian

[Christian J. (Gast)]

PS: Einen Fallstrick habe ich gefunden, bei 8 Bit Arduino und 32 Bit STM 
sind zwei gleiche Structs mit "gemischten Werten" eben nicht gleich 
lang, weil da "aligned" wird. Die auf dem STM32 sind immer größer. Daher 
musste ich alle Zahlenwerte auf 32 Byte arduino seitig erweitern. Sonst 
"treffen" die bei ihrem Empfänger nicht auf die richtigen Speicherzellen 
des Structs.__attribute_packed(()) für den Szructs wollte ich nicht 
verwenden, davor lese ich überall Warnungen.

Aber das hat nichts mit der Hardware zu tun....

[Daniel R. (sparker)]

Ich entschuldige mich, aber ich muss schon etwas schmunzeln. ;-)

Ich habe diese Dinger vor über einem Jahr beiseite gelegt (um nicht zu 
sagen: an die Wand geworfen), weil ich dieselben Probleme hatte. Das war 
auch das erste Mal, dass ich ein Problem nicht auf Anhieb lösen konnte.

Sämtliche angeblich funktionierende Routinen vereinfacht, trotzdem 
rätselhaftes Verhalten (Aufhänger, keine Datenpakete beim Empfänger).
Versorgungsspannung stabilisiert, Durchkontaktierung versucht 
nachzulöten...

Ein Programm hat interessanterweise fast funktioniert, aber da sind nur 
sporadisch Datenpakete empfangen worden. (so mit 80% Ausfallsquote)

[S. R. (svenska)]

Du machst natürlich mal wieder alles falsch und wunderst dich, dass 
nichts geht. Für dein struct-Problem ist __attribute__((packed)) nämlich 
die Lösung, die du absichtlich ablehnst. Zugriffe darauf werden auf dem 
STM32 passend ausmaskiert und sind daher geringfügig langsamer.

Du darfst auch __attribute__((packed)) mit __attribute__((align(4))) 
verbinden, dann erweitert der Compiler automatisch passend und 
garantiert dir, dass die Felderoffsets auf beiden Systemen gleich sind.

Mit den nRF24L01 habe ich in der Uni mal gearbeitet. Mein Sender ist 
immer abgestürzt, wenn ich größere Datenmengen verschickt hatte. Danach 
hatte ich mich auf "10 Pakete á 16 Byte pro Sekunde" beschränkt und es 
lief einigermaßen stabil - solange ich nicht versucht habe, mehr Daten 
in den FIFO zu schieben, als reinpassten.

[Philipp K. (philipp_k59)]

Schonmal Arduino gegen Arduino versucht als vergleichsfall?

Habe aus Spaß einen Joystick mit nem quadcopter verbunden..

das geht naja Slowly ab mit 50x6Byte die Sekunde,halt nur Arduino gegen 
Arduino... sehr zuverlässig.

[Adib (Gast)]

Hallo Christian,

Lass doch mal deinen Code sehen ... ansonsten lässt sich keine seriöse 
Antwort finden.

Adib.

[Christian J. (Gast)]

Adib schrieb:
> Hallo Christian,
>
> Lass doch mal deinen Code sehen ... ansonsten lässt sich keine seriöse
> Antwort finden.
>
> Adib.

Ist nur Testcode derzeit..... ganz unten die Routine auf die es ankommt. 
Da steht natürlich jetzt nur ne Schleife drin, damit ich die Screenshots 
machen konnte. Normalcode unten als Kommentar beiseite geschoben.

Ich pfeffer die Module bald an die Wand, so einen Shice habe ich noch 
nie gehabt.

[Heinz A (Gast)]

Sollte CSN nicht innerhalb statt ausserhalb der for-Schleife im 
EXTI1_IRQHandler getoggelt werden?

[Christian J. (Gast)]

Heinz A schrieb:
> Sollte CSN nicht innerhalb statt ausserhalb der for-Schleife im
> EXTI1_IRQHandler getoggelt werden?

Nein. Multibyte SPI Transfer. CSN schaltet die SPI ab, dann wären Read 
Befehle sofort "vergessen"

[Heinz A (Gast)]

Sieht in deinem Screenshot aber merkwuerdig aus, CSN ist da immer low, 
und da du NSS als "soft" einstellst, macht dein SPI-Modul da gar nix 
automatisch. Wie sieht's denn aus wenn CSN in der Schleife getoggelt 
wird?

[Christian J. (Gast)]

Philipp K. schrieb:
> Schonmal Arduino gegen Arduino versucht als vergleichsfall?

Müsste ich zusammen frickeln ..... fehlt mir derzeit der Nerv zu, da es 
mich noch weiter weg führt. Wenn das funktioniert nützt mir das auch 
nichts für den STM32. Wer weiss, vielleicht streikt ja auch die SPI ....

PS: Die teuren Module mit der Antenne dran laufen gar nicht, weder als 
Sender noch als Empfänger. Und ich hab rudelweise diese Dinger hier, 
alle Varianten.-

[Christian J. (Gast)]

Heinz A schrieb:
> Sieht in deinem Screenshot aber merkwuerdig aus, CSN ist da immer low,
> und da du NSS als "soft" einstellst, macht dein SPI-Modul da gar nix

Ich checke es grad ... sieht seltsam aus....

[Christian J. (Gast)]

Erzeugt das Gleiche... war mir aber schon klar. Das NRF24 Modul 
antwortet immer mit dem Status, egal was reinkommt....

So schauts jetzt aus, nach genau 32 Bytes steigt es aus.... zuzüglich 
dem Müll da noch weiter rechts. Das kann doch nicht normal sein! Oder 
das Modul liegt zu nahe an der CPU, die müllt emv mässig auch nett rum.

SPI Baudraten habe ich schon variiert... unter 250khz geht nix mehr, 
über 4 Mhz auch nicht. Unter 250khz ist seltsam. Aktuell eben 1.3 Mhz. 
Ändert aber nix.

[Heinz A (Gast)]

Kannst du das gleiche auf dem Arduino ausprobieren? Oder die Module 
austauschen?

[Christian J. (Gast)]

Heinz A schrieb:
> Kannst du das gleiche auf dem Arduino ausprobieren? Oder die Module
> austauschen?

Nee.... so auf die Schnelle nicht. Müsste ich erst aufbauen, 
programmieren usw. Das wird aber nicht das STM32 Problem lösen. Der 
Arduino sendet derzeit nur Pakete und das macht er richtig.

Das STM32 Programm oben macht nichts weiter als Bytes raushauen. Völlig 
ohne Sinn. Und reicht um die Kiste abschmieren zu lassen.

Ist das hier so ok? Start der Kommunikation? Vielleicht irgendwas 
übersehen.

[Heinz A (Gast)]

Christian J. schrieb:
> Ist das hier so ok? Start der Kommunikation?

Sieht mit blossem Auge gut aus...

[Christian J. (Gast)]

Hier das Ergebnis von 100 x 0xff, also nur Statusabfrage. (2 
Möglichkeiten, entweder Register lesen oder 0xff senden)

Nach 32 Bytes ist Ende.... später dann etwas Müll....




    for (uint16_t i = 0; i <100; i++) {
        CSN_LOW;
        SPI_TransferByte(0xff);
        CSN_HIGH;
    }

[Christian J. (Gast)]

Auch etwas Müll mittendrin. Ich habe so das Gefühl, dass da irgendwas 
"out of sync" ist, also ein sich quasi addierender Fehler auftritt und 
das RF Modul kann da nicht mehr interpretieren was es sieht. Oder 
irgendein Zähler in dem Ding läuft über....

[Christian J. (Gast)]

So... noch jemand da?

Es geht (vorerst!!) und zwar indem ich die Leseroutine verändert habe, 
dass ich bei Eintritt das Modul in den Power Down Mode setze. Alternativ 
geht auch nach dem Lesen ein PowerDown und PowerUpRX. Und der Datensatz 
darf nicht zu lang sein.

Fazit: Mit der SPI in diesem China Kracher stimmt was nicht aber 
scheinbar kann man das Problem umgehen, indem man das Modul nach jedem 
Empfang einfach aus und wieder einschaltet.

Ich schaue mir das nochj ne Weile an, wie die Daten von der Küche ins 
Arbeitszimmer flitzen und werde diese verfluchte Routine dann nicht mehr 
anfassen......

oid EXTI1_IRQHandler()
{
    uint8_t *ptr;

    /* IRQ Flag prüfen auf Fehlinterrupt*/
    if (EXTI_GetITStatus(EXTI_Line1) == RESET)
        return;

    /* Power down zum Lesen */
    RF_PowerDown();

    GPIO_SetBits(TM_DISCO_LED_PORT,LED_GREEN);

    if (RF_DataReady())
    {
        GPIO_SetBits(TM_DISCO_LED_PORT,LED_ORANGE);
        ptr = (uint8_t*)&rf_data;
        CSN_LOW;
        SPI_TransferByte(NRF24L01_CMD_R_RX_PAYLOAD);
        for (uint8_t i = 0; i < PAYLOAD_SIZE; i++)
             *(ptr++) = SPI_TransferByte(0xff);
        CSN_HIGH;
    }

    /* Fifo löschen, Status löschen */
    RF_PowerUpRx();

    /* Lösche interrupt flag */
    EXTI_ClearITPendingBit(EXTI_Line1);

}

[Philipp K. (philipp_k59)]

Christian J. schrieb:
> Und ich hab rudelweise diese Dinger hier,
> alle Varianten.-

Ja ich auch.. wenn es probleme gab egal ob mit SMA Verstärker oder ohne, 
hat immer nen 10uF direkt an den Pins geholfen. Teils war auch mal nen 
Pin vom Header nicht richtig verlötet.

[Jojo S. (Gast)]

Zeichne mal das IRQ Bit im LA mit auf. Im Datenblatt steht:

'Note:
The 3 bit pipe information in the
STATUS
 register is updated during the
IRQ
pin high to low
transition. The pipe information is unreliable if the
STATUS
 register is read during an
IRQ
pin
high to low transition.'

Dann kommt der 'Müll' evtl. daher?

[Christian J. (Gast)]

War ne kurzer Traum ...... es lief kurz und dann blockte es wieder. 
Immerhin etwas länger als vorher, etwas scheint es zu bringen. 10uf hab 
ich natürlich dran, liest man ja überall diese Wunderpille.


Und was soll man da jetzt sehen am Int Pin? Der ganz unten...

[Christian J. (Gast)]

PS:

Das Funkmodul fliegt raus aus der Anwendung. Mehr als 4 Tage reichen um 
festzustellen, dass dieser Mist nichts taugt. Kennt jemand ein Modul, 
was zuverlässig auf ähnlicher Basis arbeitet? RFM12 scheinen ja nicht 
mehr ganz so aktuell zu sein, die gabs schon vor 10 Jahren. Was ist denn 
so Neues auf dem Markt?

[Christian J. (Gast)]

Tja....

wie soll man das erklären? Das ganze Projekt auf das Notwendige runter 
gestripped und die Schaltung auf einem neuen Bord aufgebaut, nur noch 
das Funkmodul dran und nichts anderes. Dazu den LA.

Sobald ich genau diese Sequenz herausnehme, die mit dem Modul nichts zu 
tun hat läuft es durch, ohne zu mucken. Nehme ich die wieder rein, geht 
es sofort nicht mehr. Ebenfalls wenn Port Mode auf Input gestellt wird. 
Das sind nur Leds dran.

Solche Dinge sind für mich einfach nicht erklärbar. Port E hat mit dem 
Modul absolut nichts zu tun. Und auch sonst ist keine Hardware vom Disco 
auf PortE angeschlossen, die da stören könnte.

Das war es definitiv, läuft einwandfrei durch!

Ich kann den Code gern jemand geben, der ebenfalls ein 407 Disco hat und 
ein Funkmodul. Die Erklärung hätte ich wirklich gern, was Port E mit dem 
Einfrieren des SPI Busses zu tun hat !!!

    // Port E mit den Wetter Tendenz LED einstellen
//    GPIO_StructInit (&GPIO_InitStructure);
//    GPIO_InitStructure.GPIO_Pin     = WLED_ROT1 | WLED_ROT2| WLED_GLB | WLED_GRN | WLED_BLAU;
//    GPIO_InitStructure.GPIO_Mode    = GPIO_Mode_OUT;
//    GPIO_InitStructure.GPIO_OType   = GPIO_OType_PP;
//    GPIO_InitStructure.GPIO_Speed   = GPIO_Low_Speed;
//    GPIO_InitStructure.GPIO_PuPd    = GPIO_PuPd_NOPULL;
//    GPIO_Init(GPIOE, &GPIO_InitStructure);

[Jojo S. (Gast)]

Glückwunsch! Ich finde so hast du einen Fehler gut gesucht. Wenn das 
offensichtliche nicht der Fehler ist dann muss man die Kreise grösser 
und grösser ziehen. So war auch meine Idee mit dem IRQ überwachen zu 
verstehen, der hätte ja auch irgendwie flattern können. Wenn ich dir 
gesagt hätte, schalte den PortE ab hättest du mir auch den virtuellen 
Vogel gezeigt...
Aber wenn das mein akutes Problem wäre dann wäre ich auch glücklicher 
wenn so etwas in irgendeinem Errata auftauchen würde oder im Datenblatt 
in einem Nebensatz erwähnt würde. Ist das wirklich der einzige 
Unterschied zur nicht funktionierenden Umgebung? Meine nächste Idee wäre 
sonst das es irgendwo in der Systeminitialisierung liegt weil du ja 
schon einige merkwüdige Fehler beobachtet hast.
Ich drücke dir weiterhin die Daumen für maximale Erfolge.

[Christian J. (Gast)]

Jojo S. schrieb:

> Ist das wirklich der einzige
> Unterschied zur nicht funktionierenden Umgebung? Meine nächste Idee wäre
> sonst das es irgendwo in der Systeminitialisierung liegt weil du ja
> schon einige merkwüdige Fehler beobachtet hast.

Mich lässt das auch nicht los.

- Anderes Disco Board was nicht in der Anwendung steckt mit ihren vielen 
Teilen
- NRF24L01 direkt an die Pins dran gestöpselt
- LA Logger mit drüber
- Keinerlei Extra Hardware
- Das Projekt schrittweise gelöscht bis fast nichts mehr da war.

Durch Zufall, weil eine LED nicht leuchtete auf die Init Port Routine
gekommen, da stufenweise alles wegkommentiert, immer wieder am LA 
nachgeschaut ...... peng, Port E! Entweder alles raus oder die Direction 
ändern.

Wäre an Port E was dran würde ich auch auf Überlastung tippen aber Port 
E ist ja leer, die LED sind in der Anwendung drin.

Das ist der Rest:

//////////////////////////////////////
/*         Hauptprogramm            */
//////////////////////////////////////

/* Delay Timer */
volatile uint32_t        delaytimer;
volatile uint32_t        millis;                // Millisekunden seit Systemstart

void SysTick_Handler() {

    delaytimer++;
    millis++;
}

// Verzögert die Ausführung um N Millisekunden
void DelayMs(uint32_t msec) {

    delaytimer = 0;
    while (delaytimer < msec);
}


int main(void)
{

    //////////////////////////////////////
    /* Initialisierung des Systems      */
    //////////////////////////////////////

    SystemInit();                                           // Init der Clocks und wichtiger Register
    SysTick_CLKSourceConfig(SysTick_CLKSource_HCLK);        // Systick einstellen
    SysTick_Config(SystemCoreClock/1000);
    TM_DELAY_Init();
    TM_DISCO_LedInit();
    Init_Ports();

    /* Funkmdoul einstellen */
    RF_SPI_Init();                                          // SPI justsieren
    RF_Configure();                                         // NRF24L01+ einstellen
    RF_NVIC_Init();                                         // ISR Vektor umbiegen

    if (RF_Available()) {
        flags.NRF24L01_IsPresent = true;
        flags.rf_timeout = true;
    }
    else
        while (1);

    NVIC_EnableIRQ(EXTI1_IRQn);


    while (1) {
        DelayMs(1000);

        if (nrf24l01_NewTempAvailable) {
            GPIO_ResetBits(GPIOD,LED_GREEN);
            GPIO_ResetBits(GPIOD,LED_RED);
            GPIO_ResetBits(GPIOD,LED_ORANGE);
            GPIO_ResetBits(GPIOD,LED_BLUE);
            nrf24l01_NewTempAvailable = false;          /* Flag reset, Wert wurde verarbeitet */
        }

    }

}

Einmal hatte ich was Ähliches... LED Flattern. Pin 1 ein, Pin 4 ging mit 
an und dimmte so vor sich hin. Da war aber die CPU kaputt, EMV 
vermutlich.

Ich schaue mir die Errate mal an, Port E ist auf dem Disco frei, da ist 
nix dran auf den Bits 4-9.

[Jojo S. (Gast)]

Welches Board ist da denn genau? Habe auch eines der ersten F4 und 
gerade ein neues mit M4 und eins mit M7 bekommen. Aber die STM32 werden 
mir gerade immer unsympathischer :-) Weiß nicht warum die ganze Welt da 
gerade so drauf abfährt, meine favorisierten LPC verhalten sich da 
wesentlich unauffälliger.

[Christian J. (Gast)]

Nüscht..... Errata ist endlos lang aber alles nur so Spezialsachen, die 
so keiner braucht. I2C ok.... da ist einiges zu drin und auch DMA.

Ich habe 3 Boards mit dem 407VG drauf, die STM32F407Vg Disco. Früher 
habe ich auch LPC2368 benutzt, immer schön Register Programmieren, ganz 
ohne Libs. Grad aber im Markt verkauft das Board. Lief nur mit Jtag und 
Wiggler in Verbindung mit Rowley Crossworks, keine swd Unterstützung, 
st-link sowieso nicht.

Entweder habe ich das was übersehen und Port E hängt doch irgendwie mit 
der SPI 1 zusammen oder da bricht irgendwie die Spannung im Chip 
zusammen. Es muss nicht das RF Modul sein, es kann genauso gut sein, 
dass die SPI ein Problem hat! Das ist nicht unterscheidbar auf dem LA.

Aber diesen Effekt habe ich jetzt auf 2 Boards nachvollzogen, die sind 
nagelneu.

Montag werde ich in der Firma erstmal alle Chips runter-heisslöten, die 
ich eh nicht brauche, den Audio DAC, Gyro und Mikrofon usw.

PS: Es läuft immer noch, 1090 Datensätze fehlerfrei vom Arduino zum 
STM32. Toi, toi, toi... ich wünschte Merkel hätte auch solch lösbaren 
Probleme grins

[Jojo S. (Gast)]

Ich habe zum Ausgleich erstmal Rammstein live Amerika reingeworfen. 
Hilft auch :-)

[Christian J. (Gast)]

Jojo S. schrieb:

> Ich habe zum Ausgleich erstmal Rammstein live Amerika reingeworfen.
> Hilft auch :-)

https://www.youtube.com/watch?v=e-f9ulkmdcA
https://www.youtube.com/watch?v=OIZDwDZ2yM8

:-)

[Jojo S. (Gast)]

Beides Top! Habe auch mal eine PN geschickt.

[Dr. Sommer (Gast)]

Christian J. schrieb:
> Entweder habe ich das was übersehen und Port E hängt doch irgendwie mit
> der SPI 1 zusammen oder da bricht irgendwie die Spannung im Chip
> zusammen.

Hast du mal die I/O Compensation Cell versucht? Kannst du mal 
Oszillogramme (nicht LA!) von den SPI-Leitungen machen, mit PortE an vs. 
aus? Vielleicht sieht man einen Unterschied...

[Christian J. (Gast)]

Dr. Sommer schrieb:
> Kannst du mal
> Oszillogramme (nicht LA!) von den SPI-Leitungen machen, mit PortE an vs.
> aus? Vielleicht sieht man einen Unterschied...

Mangels Oszi leider nicht. Muss mir mal wieder einen anschaffen.

Ich schalte auch gern den Flux-Kompensator ein, wenn Du mir sagst 
welches Register das ist...

Moment.... ist in stmF4xx_syscfg....

SYSCFG_CompensationCellCmd(ENABLE);      // Was auch immer das ist...

Port E wieder ein....Flashen.... Board ausschalten um Bits zu resetten 
.....starten..... gucken.....

Nö! Schmiert wieder ab. :-( Aber ich lass sie mal an, fürs gute Gefühl.

Vielleicht mal den Prescaler des APB2 runtersetzen? Der steht auf 1:1. 
Aber dann läuft alles langsamer, auch die SPI usw.

Das kann alles nicht sein, das müsste schon vorher 10.000 anderen 
aufgefallen sein. Vielleicht liegt es aber eben auch am Disco Board.

[Dr. Sommer (Gast)]

Christian J. schrieb:
> Vielleicht mal den Prescaler des APB2 runtersetzen? Der steht auf 1:1.
> Aber dann läuft alles langsamer, auch die SPI usw.

Ja, das ist falsch. Der APB2 darf auf maximal 84MHz laufen (siehe S. 77 
im Datasheet), und wenn du den Prozessorkern auf seinem Maximum von 168 
MHz betreibst muss der Prescaler also mindestens 2 sein. Um SPI schnell 
genug zu machen, musst du ja nur den SPI-Prescaler wieder erhöhen, denn 
ich bezweifle dass du SPI gerade beim jetzigen Maximum von 168 MHz 
betreibst.

[Tomas (Gast)]

Versteh gar nicht wo das Problem liegt. Mit einem Arduino und den 
kleinen Transmittern gabs hier noch nie Probleme. Die lib ist wohl recht 
gut

[Dr. Sommer (Gast)]

Tomas schrieb:
> Versteh gar nicht wo das Problem liegt.
Wir auch nicht. Daher wird hier Fehlersuche betrieben.

[Christian J. (Gast)]

Tomas schrieb:
> Versteh gar nicht wo das Problem liegt. Mit einem Arduino und den
> kleinen Transmittern gabs hier noch nie Probleme.

Die Arduinos laufen auch nicht mit 168 Mhz, haben 8 Busse mit zig 
Vorteilern! Und wie ich jetzt weiss liegt das Problem auch eher am 
Cortex 4 und nicht an dem Modul. Bzw. vermute ich das. Kann natürlich 
sein, dass die Funken eine zu starke Pin-Last sind usw. usw.

In der Radio Head Lib ist jedenfalls ein Fehler, den habe ich schon 
gesehen. CSN wird nicht Low gesetzt vor dem Lesen. Dass es trotzdem 
klappt ok, ist aber nicht wie im Datenbuch.

Kann jedenfalls jeder nachvollziehen: Disco Board, 7 Female Stecker, 1 
NRF Modul und meine Test-Software.

Nacht!

[Christian J. (Gast)]

PS:

Problem ist gelöst, Port E ist auch wieder dabei!

.... mit einem Drehmel :-)

Gruss,
Christian

[Adib (Gast)]

Hallo Christian,

ich weiss jetzt, su arbeitest mit dem STM32F4.
Schau dir doch bitte mal das CubeMx an.
Es gibt da einen Konfigurator für die Clocks.
Es sagt ja keiner, dass du das Ding nehmen musst. Es reicht ja schon, 
aus dem generierten Code die Parameter rauszuklauen ....
Anbei mal ein Screenshot von einer F1-Konfiguration.
Die Dinger mit 1000 Optionen haben leider auch 999 Möglichkeiten, was 
falsch zu konfigurieren.

Ich habe auch irgendwie das Gefühl, du bleibst immer die fehlerursache 
und deren Lösung schuldig.

Was genau hast du denn gedrehmelt ... ?

Grüße, Adib.

[Christian J. (Gast)]

Adib schrieb:

> ich weiss jetzt, su arbeitest mit dem STM32F4.
> Schau dir doch bitte mal das CubeMx an.
> Es gibt da einen Konfigurator für die Clocks

Ich lads grad runter. Habe auch so eine Excel Tabelle aber letzlich 
stell ich die einmal ein und dann nie wieder. Vollgas und gut ist es.

Naja, mal auf die Uhr geschaut meiner letzten Beiträge? Über die viele 
Frickelei mit dem Disco Board und immer mehr dran bauen habe ich 
übersehen, dass das Ding oben drauf auch ne Menge Gemüse hat. Und die 
SPI1 ist über ihre I2C Funktion an den Gyrosensor angetackert. Naja, und 
der scheint sich wohl zwischendurch mal "gemeldet" zu haben :-( Das tut 
er jetzt nicht mehr, da ich den bis aufs Board runter gedrehmelt habe. 
Montag in der Firma lasse ich auch die anderen Boards alle ent-IC'en, da 
ich das Zeug da drauf eh nicht brauche, wie Audio DAC usw. Das stört nur 
die anderen Pins. Habe mir auch die SPI verhundelt durch Änderung der 
Taktgeschwindigkeiten der Pins und dann lief nichts mehr. 
Glücklicherweise habe ich einen kleinen Server, der alle Stunde ein 
Backuip zieht, eines zurückgezogen grad wo noch alles lief und dann die 
Änderungen wieder eingebaut. Man muss echt jeden Schritt testen, sost 
geht nachher gar nichts mehr und man weiss nicht welche Schraube man 
zurückdrehen muss.

So, Download ist fertig...

[Jojo S. (Gast)]

Christian J. schrieb:
> Über die viele
> Frickelei mit dem Disco Board und immer mehr dran bauen habe ich
> übersehen, dass das Ding oben drauf auch ne Menge Gemüse hat.

Darum verstaubt das Disco Board auch bei mir im Regal. Mit dem Zeug 
drauf kann man ein bisschen programmieren üben oder verschiedene Libs 
austesten, aber um es irgendwo sinnvoll einzusetzen taugt es nicht. Ist 
viel zu gross für einfache Steueraufgaben, da finde ich die einfachen 
Breakout Boards viel praktischer. Interessant wäre das Disco F4 mit 
Ethernet, aber für den Phy war ST dann wohl doch zu geizig (ist auf den 
Nucleos auch nicht zu finden, oder?).
Richtig geil ist dafür das STM32F469 mit Chrome-ART Beschleuniger und 
einem guten Display. Das ist schon eine Steuerzentrale, Grafik wie ein 
Handy und dazu Steuermöglichkeiten eines µC. Für die Grafik wird da 
TouchGFX verwendet, da habe ich aber noch keinen Einstieg gefunden. Es 
gibt zwar auch eine Eval Version, aber in der Runtime tauchen dann immer 
TouchGFX Einblendungen auf. Eine Vollversion ist für Hobby leider zu 
teuer.
Sorry wenn Off Topic aber das wollte ich mal sagen.

[Adib (Gast)]

Hallo Christian,

wo hast du das denn gelernt?

/* Extrahierter Inhalt des Status Registers */
typedef struct {
    _Bool    rx_dr;         // Data Ready RX Fifo Interrupt
    _Bool    tx_ds;         // Data Sent FIFO Interrupt
    _Bool    max_rt;        // Maximum Numer of Retransmits reached
    _Bool    tx_full;       // TX FIFO Full flag
    uint8_t  rx_p_no;       // Data pipe for paypload avalable for reading (0..5)
} status_t;

besser Bitfelder benutzen:

typedef struct {
    unsigned int    rx_dr: 1;         // Data Ready RX Fifo Interrupt
    unsigned int    tx_ds: 1;         // Data Sent FIFO Interrupt
    unsigned int    max_rt: 1;        // Maximum Numer of Retransmits reached
    unsigned int    tx_full: 1;       // TX FIFO Full flag
    unsigned int  rx_p_no: 4;       // Data pipe for paypload avalable for reading (0..5)
} status_t;

wie empfängst du denn Daten im STM32 mit dem 24l01?
Ic hhabe nur die SendPayload Methode gesehen.

Grüße, Adib.

[Christian J. (Gast)]

Adib schrieb:
> besser Bitfelder benutzen:

Nein. Man benutzt die Datentypen, die der Compiler vorgibt und das ist 
Bool.
Bei 192kb ist es völlig wumpe wieviel Platz ein Flag einnimmt und der 
Stm32 kann außer Bitbanding keine Einzelbits ansprechen. Bitbanding wird 
aber natürlich nicht automatisch erzeugt.

Alles schon so in Ordnung.... das bleibt so.

[Christian J. (Gast)]

Adib schrieb:
> wie empfängst du denn Daten im STM32 mit dem 24l01?
> Ic hhabe nur die SendPayload Methode gesehen.

Per Interrupt natürlich. Das klappt alles bestens jetzt, wunderbar. Duie 
Bits fliegen nur so durch die Wohnung, man muss sich fast ducken um 
nicht getroffen zu werden :-)

[Adib (Gast)]

Was war denn jetzt genau das Problem?
Wie sieht deine Lösung aus?

Grüße, Adib.
--

[Nobody (Gast)]

Adib schrieb:
> Wie sieht deine Lösung aus?
Statt den CS Pin des Gyros auf High zu ziehen, lieber das Dingen mit dem 
Dremel töten.
;-) (sorry) ;-)

[Jojo S. (Gast)]

Der Dremel ist die Hardware Lösung, aber bevor du deine anderen Boards 
schredderst: Laut Doku ist der MEMS Sesnor ja mit CS an Port E3. Wenn 
der nicht initialisiert ist floated der vor sich hin und wird sporadisch 
die Störungen verursacht haben.
Die SW Lösung wäre demnach Port E zu initialisieren und E3 auf 0 zu 
setzen.

[Christian J. (Gast)]

Nobody schrieb:

> Statt den CS Pin des Gyros auf High zu ziehen, lieber das Dingen mit dem
> Dremel töten.
> ;-) (sorry) ;-)

Ich habe die anderen Boards bei uns mit Profi Equipment auslöten lassen. 
Alles runter was im Wege ist. Da alle Pins direkt mit den Außenpins 
verbunden sind kann man da grossflächig "abernten" bzw "runterschaben". 
Schön mit Bildschirm Mikroskop Lupe alles geprüft auf Kurzschlüsse. Die 
Module spielen einwandfrei, seit 2 Tagen. Der Außensensor funkt alles 
durch, Luftdruck, Feuchte, Temperatur, Regensensor, Batteriespannung 
usw.