2014-04-24 10:43 AM
Hi,
I have to revceive data from a device that is sending I2S with 8 bit data format....The smallest I see is theI2S_DataFormat_16b,...
Is there a way that I can receive correctly this 8 bit data format?Thanks2014-04-24 12:13 PM
Slave Mode SPI? Otherwise probably not.
2014-04-24 12:31 PM
Hi,
I have to play the role of slave only.What exactly do you suggest?To use as SPI slave and trash all the 9th bit? Or to play somehow with chip select?2014-04-24 01:08 PM
To use as SPI slave and trash all the 9th bit? Or to play somehow with chip select?
Yeah, I'm not familiar with any 9-bit issues. I'm familiar with streams where the WS toggles for left/right channels, and a PCM mode where WS indicated the next frame. If the channel remains on, and synchronous, I'd imagine you could capture the stream and extract the bits/bytes you need. Initial synchronization is perhaps a little problematic. You could perhaps measure the WS edge, wrt RXNE? Perhaps you can do something with a CPLD?2014-04-24 02:18 PM
I never heard of 8-bit I2S, although the specification does not exclude it. Is it an 8-bit frame (i.e. 8 clocks between WS edges), or some other clock scheme? Could you please post link to the device's datasheet, or at least its timing diagram?
Why don't you simply try. If it *is* an 8-bit *frame*, it will work with the I2S module in STM32 being set to 16-bit format. There is a requirement to start the I2S module when WS is in inactive state (see errata) so obey that. JW2014-04-24 09:05 PM
Hi,
I have to admit that I'm not an expert of I2S, butlooks like a ''proper'' 8 bit frame. (see attachement) Can you tell me where I can find the mentioned errata ? Thanks ________________ Attachments : I2S.jpg : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0jn&d=%2Fa%2F0X0000000bd9%2FL5gJlHdhTnzielPv_tfkC7bGqvIdhHnuPjJrBB4GG_o&asPdf=false2014-04-25 12:34 AM
I could manage that it is sending 16 bits.
But I still not get what I see on the oscilloscope (look annex). The errata tells: In slave mode the WS signal level is used only to start the communication. If the I2S (inslave mode) is enabled while the master is already sending the clock and the WS signallevel is low (for I2S protocol) or is high (for the LSB or MSB-justified mode), the slave startscommunicating data immediately. In this case the master and slave will be desynchronized throughout the whole communication. Workaround The I2S peripheral must be enabled when the external master sets the WS line at: (A)– High level when the I2S protocol is selected. (B)– Low level when the LSB or MSB-justified mode is selected. Now I do not know how to interpret it, and I'm not sure what shall I do on my case. From the 16 bits I only need the first 8 that are sent (the other I can trash). Question1: ''..The I2S peripheral must be enabled when the external master sets the WS line at... Means that I2S peripherial must be enabled BEFORE the external or Means that I2S peripherial must be enabled AFTER the external Question2: [UPDATE: I think that I should use the 1) because I have the dummy bit] For this signal,what shall I select as standard? 1)I2S_Standard_Phillips and consider workaround A)
2)I2S_Standard_MSB
and consider workaround B)
Question3: Where can I find some documentation about those standards (Philips, MSB, LSB, PCMshort...)? ________________ Attachments : I006_I2S_16bit_ok.bmp : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0hd&d=%2Fa%2F0X0000000bd8%2FySDrLiQ36oqCd9E_IuJAdhxJHiyzkp0YQQsQbo.jGp4&asPdf=false2014-04-25 04:11 AM
> I could manage that it is sending 16 bits.
It is 17 bits frame. I am afraid the SPI/I2S module in STM32 is not that flexible that it could cope with it - it supports only fixed length 16/32-bit frames. Strictly speaking, the I2S implementation here does not conform to the I2S specification, which allows arbitrary bit-length frames as long as they contain at least as much bits as the co/dec needs. And it's not I2S either - I2S is stereo, WS determining the left-right (it's often called LRCK) sample. This one resembles what in the ST manual is called PCM. I believe, you *could* receive the data even when transmitted in non-16-bit frame, but at the cost of them being shifted by 1 bit in each read word, so that you would need to reconstruct them ''manually'' in software. Additionally, you lose the ability to detect synchronization errors, and the frame error flag will be always on. Coincidentally, somebody else has described a similar problem in a parallel thread: https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%2fSTM32F4%20I2S%20Frame%20Error&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&TopicsView=https%3A%2F%2Fmy.st... JW PS. Where can I find some documentation about those standards (Philips, MSB, LSB, PCMshort...)? For I2S (Philips), simply google for ''I2S specification''. I am not aware of any formal document specifying MSB/LSB and I believe these are ad-hoc protocols created by competing companies, for example what is here described as LSB I used to find under ''Sony-I2S'' header. in various materials. PCM probably originates in the phone industry, but I am not aware of any standard for that either.2014-04-25 04:21 AM
I found out on one document the difference between the standards.
The Philips one for the 16 bits has the 17clocks and the first clock is not used for a bit transfer.The PCMshort has 16clocks and uses the first clock for a bit.Finally I could get my data on this way:- configure the sender to generate 16 clocks- I use the PCMshort standard and at interrupt I just take what I needmyData = (uint8_t)(rxData>>7)Later I will have a look to the parallel item.. :)Thanks to participate at the discussion and to give me some hints.2014-04-25 04:38 AM
> The PCMshort has 16clocks and uses the first clock for a bit.
Then that should work with the STM32. > Later I will have a look to the parallel item.. :) You don't need to, as you've found the solution in configuration of the other chip. JW