I2C via DMA på STM32F4xx, exempel? *blev lite annat*

[Korken]

Jag testade i arm-none-eabi-gcc och då fungerade det med volatile medlemmar i structen.
Jag testade inte de andra fallen då fallet jag använder fungerar.

/* Fotnot */
Jag måste säga att jag hatar osymetrin i läsningarna av I2C hos SMT32F4an.
Det gör att state-machinen för läsningar blir väldigt komplex och svårläst.

[kimmen]

Testade i avr-gcc, och där gav fall 3 (volatile pekare) samma resultat som fall 1. Övriga fall gav samma resultat. Så enligt avr-gcc hade jag alltså inte fel. Första testet gjorde jag med Freescale Codewarrior för HCS08.

Var inte fall 3 "volatile abc_t* abc;" - dvs. non-volatile pekare till volatile abc_t? Och fall 1 var att fälten i structen var volatile? Jag hade väntat mig att båda skulle fungera utan bortoptimering av läsningen, vilket om jag förstod ditt inlägg rätt det alltså gjorde i GCC men inte i Codewarrior?

Fall 4, dvs. "abc_t* volatile abc;" blir en volatile-pekare till en non-volatile abc_t, och det verkar rimligt att man då läser adressen från variabeln abc men struntar i att läsa vad den pekar på.

[bearing]

Jag hade väntat mig att båda skulle fungera utan bortoptimering av läsningen, vilket om jag förstod ditt inlägg rätt det alltså gjorde i GCC men inte i Codewarrior?

Ja, Codewarrior optimerade bort fall 3 (EDIT: även dubbelkollat idag). Optimeringsgraden är -Os för båda kompilatorerna.

Jag hade visst blandat ihop hur deklarering fungerar.
volatile abc_t* abc; ger alltså en pekare till volatile struct.
abc_t* volatile abc; ger en volatile pekare till struct. Om jag förstått rätt är detta samma sak som abc_t volatile* abc; vilket visar tydligare att det handlar om en volatile pekare.

[kimmen]

C:s deklarationssyntax kan kännas lite bak och fram ibland. Eller så är det så att det är så hela tiden. Man får ut en ganska vettig beskrivning om man läser från höger till vänster.

abc_t volatile *abc; är faktiskt samma som volatile abc_t *abc;.

Den första kan ju då läsas som "pekare till volatile abc_t". Den andra blir samma, för ordningen mellan en typ och "type-qualifier" spelar ingen roll.

[bearing]

Haha, jag fick det alltså fel igen. Och nu minns jag att jag under mina försök igår såg detta, men det hade jag redan glömt.

Placeringen av stjärnan förändrar till viss del hur det "ser ut", och vad som verkar logiskt. En del programmerare föredrar att lägga stjärnan mot variabelnamnet, och andra föredrar att lägga den mot variabeltypen. Jag har börjat lägga den mot variabeltypen, eftersom att jag tycker att den hör mer hemma där. Men det verkar ju inte som att det blivit enklare att förstå, av att göra på det viset.

[kimmen]

Jag brukar placera den mitt emellan . T.ex int * intpekare;, men jag kan hålla med om att det känns bättre att ha den tillsammans med typen än variabelnamnet, även om det är den senare som känns närmare vad kompilatorn tolkar det som.

[Korken]

Nu ska vi se, jag har ett problem som jag inte lyckas lösa så tänkte se om vi har någon STM32 Guru här.
Jag testar interrupt driven läsning men inga interrupts genereras. Jag kollar SR1 registret och den säger att SB = 1 dvs att SB är generad.
Jag har ställt in mina interrupts med I2C_ITConfig(I2Cx, (I2C_IT_BUF | I2C_IT_EVT | I2C_IT_ERR), ENABLE); men ändå så genereras inte SB interruptet.

Vet någon om det är något mer som måste aktiveras för att interrupts ska genereras?
I källkodsfilen står det:

6. Enable the NVIC and the corresponding interrupt using the function I2C_ITConfig() if you need to use interrupt mode.

Och jag använder I2C_ITConfig().

[remne]

Jag kan inte STM32 (än.. ), men gjorde en snabbgoogling, har du slagit på __enable_interrupt(); ?

[kimmen]

När jag kollar på stm32f10x så slår inte I2C_ITConfig() på interruptet i NVIC om man kollar källkoden till funktionen. Kan det vara det att man måste använda NVIC_EnableIRQ() också, som i följande kod jag har för UART?

Kod: Markera allt

	
	USART_Init( MIDI_UART, &UART_InitStructure );

	/* Enable MIDI UART Interrupt */
	USART_ITConfig(MIDI_UART, USART_IT_RXNE, ENABLE);
	NVIC_EnableIRQ(MIDI_IRQn);

	// Turn on MIDI UART
	USART_Cmd( MIDI_UART, ENABLE );

[Korken]

Aha! De va det!
Hur tusan kan jag glömma att enabla vectorn i NVIC...

[Korken]

Interruptdriven I2C: Check!

logicanalyzer.png

[Korken]

Okej, nu har jag testat massa överföringar och jag har hittat en grej som jag inte vet vad det är.
Om ni kollar i den bifogade vilden och på de gröna ringarna, vad är den pulsen? Precis innan sker en ACK, men vette tusan vad som händer i de gröna ringarna.
Har någon en aning om vad detta är? Det står inget i STM32ans referensmanual om detta. Och är det ett problem?

i2c_hum.png

[kimmen]

Är det inte bara tiden mellan att slaven släpper ACK och att mästaren lägger ut första biten av nästa byte?

[Korken]

Ah, det kan det ju vara! Tänkte inte på det!
Den går hög precis efter att klockan går låg så det ser precis ut som om någon släpper bussen och den dras hög av PU innan mastern kommer in igen om styr om signalen.'
Den förklaringen köper jag helt klart.