Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for I2S protocol #87

Open
ost-ing opened this issue Oct 12, 2020 · 8 comments
Open

Support for I2S protocol #87

ost-ing opened this issue Oct 12, 2020 · 8 comments

Comments

@ost-ing
Copy link

ost-ing commented Oct 12, 2020

I'm trying to determine if the SPI implementation can support I2S? If not, any plans in the future to add this?
I assume that its related to SPI, as the datasheet for stm32f747zg suggests:

Up to 6 SPIs (up to 50 Mbit/s), 3 with muxed simplex I2S for audio class accuracy via internal audio PLL or external clock

Thanks!

@hannobraun
Copy link
Contributor

I know next to nothing about I2S, but to the best of my knowledge, it is not supported. I'm also not aware of any plans to implement it, but of course any contributions doing so would be very welcome.

@ost-ing
Copy link
Author

ost-ing commented Oct 13, 2020

Thanks for the response @hannobraun. When I find the time, I could begin to look into it.
For further reference, the stm32f429-hal implements it.

Kind regards,
Oliver

@ost-ing
Copy link
Author

ost-ing commented Nov 9, 2020

I've begun implementing I2S support, but I need some assistance regarding the way the HAL currently implements the rcc::CFGR.

I'm porting the I2S initialization C++ function HAL_StatusTypeDef HAL_I2S_Init(I2S_HandleTypeDef *hi2s).

This function requires access to:

  • system clock switch status, to determine if HSI or HSE is being used
  • the configured PLLM value
  • the plli2scfgr register, specifically the plli2sn and plli2sr values.

These values are then used to determine the I2S MCK value, which is crucial for I2S Master operation.

After calling constrain() on pac::RCC, I lose access to read these registries. Further the stm32f7xx_hal::rcc::CFGR freeze function returns a Clocks struct that also cannot help me.

Is there an example somewhere of accessing these registries (read-only) in a safe or unsafe way after constraining?
If not, I could attempt to modify the rcc.rs to allow accessing read-only values, or is there any suggestion on how to handle this situation?

cc. @hannobraun & @no111u3

Kind regards,
Oliver

@hannobraun
Copy link
Contributor

You can always conjure up an instance of pac::RCC via pac::RCC::ptr(). Or you could just add the required information to Clocks. I don't have a strong opinion here.

@ost-ing
Copy link
Author

ost-ing commented Nov 10, 2020

Thanks for pointing me in the right direction 👍

@andybest
Copy link
Contributor

andybest commented Apr 7, 2021

@ostenning Did you get anywhere with the I2S implementation? I am thinking of possibly implementing it myself if not :)

@ost-ing
Copy link
Author

ost-ing commented Apr 8, 2021

@andybest Sorry, no I ended up going in a different direction with my project. But take a look at the stm32h7xx-hal, its already implemented there.

@andybest
Copy link
Contributor

andybest commented Apr 8, 2021

@ostenning No worries! Thanks, I'll see if I can port over the implementation from there :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants